[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.