Is there also the requirement that the address of one device that sends packets to the outside not give clues about other addresses that might be in use or the network topology on the inside?
- Ralph
-----Original Message-----
From: owner-v6ops@ops.ietf.org on behalf of Fred Baker (fred)
Sent: Tue 8/23/2005 9:57 AM
To: chenhongfei
Cc: 'Eric Klein'; v6ops@ops.ietf.org
Subject: Re: Review: draft-ietf-v6ops-nap-01.txt
If the objective is to not have people on the outside know of the
existence or exact value of an address, or be able to attack it by
sending traffic to it, then a system that sends packets outside the
net would need to change addresses periodically, but a system that
doesn't send packets outside the network merely needs to be protected
from accidental uses of its address.
On Aug 23, 2005, at 5:00 PM, chenhongfei wrote:
> I don't confirm I understand your email completely.
> I agree with you that internal servers are a great reason (and
> perhaps the only real reason) for having some form of stays-inside-
> the-site address. Do you mean that the internal servers needn't to
> periodically change the address?
>
>
>
> Best regards
> Hongfei Chen
>
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Monday, August 22, 2005 5:37 PM
> To: chenhongfei
> Cc: 'Eric Klein'; v6ops@ops.ietf.org
> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt
>
> one might wonder why one is concerned about a server's address being
> known in the network...
>
> On Aug 22, 2005, at 3:05 PM, chenhongfei wrote:
>
>> It's a good solution to periodically change the address. But if a
>> server(for example DNS server) periodically change the address, The
>> services should be interrupt. How to solve this issue?
>>
>
> Any company has a set of systems that are entirely internal. Common
> ones at Cisco are either labs, or have names that start in "wwwin",
> like wwwin.cisco.com and wwwin-people.cisco.com. You can translate
> those names into addresses outside Cisco, but our firewalls prevent
> external traffic from reaching them.
>
> From my perspective, such internal servers are a great reason (and
> perhaps the only real reason) for having some form of stays-inside-
> the-site address. In a global address space, there are two things one
> should do for inside-only systems (servers, clients, or p2p systems):
> place the system in an address space that is not advertised in
> routing, and prevent DNS requests from outside the company from
> translating the name. If the firewall router cannot route to the
> address, that's a pretty cheap filter, and if the address is not sent
> outside, one won't be exercising the filter very often.
>
> ULAs are supposed to be a stays-inside-the-site address. Something
> that works just as well is a prefix or set of prefixes taken from the
> site's global space that are administratively prevented from being
> advertised to the DMZ routers. Outside, they advertise the site's
> prefix as a /48. Inside, they have routing to individual campuses or
> LANs within the site, and they don't have the LANs the internal-only
> servers are on. No packet will ever cross that DMZ to those internal-
> only servers.
>
> Notice how these are more effective filters than NAT provides (if
> there is a correlated address, the system is reachable by attacking
> the correlated address), and are very cheap (you don't even have to
> configure an ACL or stateful firewall rule in the data path; the
> filter falls out from not having a route). It also has an interesting
> effect if the system is infected with some virus or etc that makes it
> phone home for instructions: the reply is effectively prevented from
> being sent, especially if there is an ingress filter on the ISP end.
>