Subject: Re: Review: draft-ietf-v6ops-nap-01.txt

From: Fred Baker <[email-masked]>
Date: Tue, 23 Aug 2005 21:57:14 +0800

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:[email-masked]]
> Sent: Monday, August 22, 2005 5:37 PM
> To: chenhongfei
> Cc: 'Eric Klein'; [email-masked]
> 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.
>

---

From: "Ralph Droms \(rdroms\)" <[email-masked]>
Date: Tue, 23 Aug 2005 10:02:47 -0400

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Aug 2005 06:21:30 +0800

On Aug 23, 2005, at 10:02 PM, Ralph Droms ((rdroms)) wrote:
> 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?

I'll argue that those clues already exist. The delegated prefix is  
advertised outside, and a simple traceroute sweep across the network  
can identify the routers in the network and at least some of the  
subnets. The routers will respond with "TTL expired", revealing their  
ingress subnet numbers. If the administration chooses a common host  
part for routers (such as <prefix>::0001or some such thing), it will  
be trivial for the sweeper to deduce this from the traceroute  
responses and then ping sweep the routers in the network, determining  
all subnet numbers.