[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-vandevelde-v6ops-nap-00
Overall, very nice thrust :)
has some perceived benefits. Indeed, in an Internet model based on
universal any-to-any connectivity, product marketing departments have
driven a perception that some connectivity and security concerns can
only be solved by using a NAT device or by using logically separated
LAN address spaces.
>> But it's not any-to-any, is it? Maybe "originally based on the concept
of universal any-to-any connectivity, this concept has been stifled by
product marketing departments who have sold consumers a perception..."
(and as a result, we have an Internet of consumers...)
This document describes the market perceived
reasons to utilize a NAT device in an IPv4 environment and shows how
these needs can be met and even exceeded with native IPv6. The use
>> What do you mean by "native" here? (some readers may not know)
This document describes several techniques that may be combined on an
IPv6 site to protect the integrity of its network architecture.
These techniques, known collectively as NAP, retain the concept of a
well defined boundary between "inside" and "outside" the private
network, and allow firewalling, topology hiding, and privacy and
achieve these goals without address translation.
>> Are we concerned with address translation here, or use of private (site
local) addresses? The latter has no translation, but may leak...
2. Perceived benefits of NAT and its impact on IPv4
2.2 Simple security due to stateful filter implementation
It is frequently believed that a NAT device puts in an extra barrier
to keep the private network protected from evil outside influences
due to the stateful character of NAT technology (to protect against
hackers, worms, etc..).
>> I'd not say "evil" even if it is :)
>> Also, "stateful" isn't the thing, it's that the internal (private)
addresses cannot (usually) be routed to/contacted from outside the
private network.
This benefit may be partially real; however,
experienced hackers are well aware of NAT devices and are very
familiar with the private address space, and hence the secure feeling
is in vain.
>> A little wooly; perhaps specify the vulnerability in more detail.
Address translation does not provide security on itself; for example,
consider a configuration with static NAT translation and all ports
translating to a single machine. In such a scenario the security
risk for that machine is identical as if there were no NAT device in
the communication path. As result there is no specific security
value in the address translation function. The perceived security
comes from the lack of pre-established mapping state. Dynamically
establishing state in response to internal requests reduces the
threat of unexpected external connections to internal devices.
>> And of course many vulnerabilities these days are not from IP-based
connections into a network, but from data received by the network
(emails, images, web pages, etc). NAT is just a piece of the picture.
>> Some NAT users will also map ports to enable services into their
NATed network; here the NAT adds complexity; not sure that's captured
in the draft?
2.3 User/Application tracking
Due to the fact that NAT is a stateful technology, it could provide
limited capabilities for the administrator of the NAT to gather
information about who in the private network is requesting access to
which Internet location. This can be done by checking the network
address translation details of the private and the public addresses
of the NAT devices state-database.
>> But this can be done (and is done) with non-NATed networks?.
2.4 Privacy and topology hiding
The ability NAT to provide internet access by the use of a single (or
few) global IPv4 routable addresses to a large community of users
offers a simple mechanism to hide the internal topology of a network.
In this example the large community will be reflected in the internet
by a single (or few) IPv4 address(es).
The use of NAT then results in a user behind a NAT gateway actually
appearing on the Internet as a user inside the NAT box itself; i.e.,
the IPv4 address that appears on the Internet is only sufficient to
identify the NAT. Thus it is impossible to tell from the outside
which member of a family, which customer of an Internet cafâ, or
which employee of a company generated or received a particular
packet, if concealed behind NAT. Thus, although NATs do nothing to
provide application level privacy, they do prevent the external
tracking and profiling of individual host computers by means of their
IP addresses. At the same time it creates a smaller pool of
addresses for a much more focused point of attack.
>> There is a similarity with app-level, in that a NAT offers similar
"privacy" for web users as a web cache (although the details of what
is - or is not - logged at the NAT/proxy will be deifferent).
Some enterprises prefer to hide as much as possible of their internal
network topology from outsiders. Mostly this is achieved by blocking
"traceroute" etc., but NAT of course entirely hides the internal
subnet topology, which some network managers believe is a useful
precaution to mitigate scanning attacks.
>> Perhaps talk somewhere about two-faced DNS, which is used to
support this model.
>> Also scanning in v6 can be much harder, by obscurity (see
draft-chown-v6ops-port-scanning-implications-01)
2.5 Independent control of addressing in a private network
Due to the ongoing depletion of the IPv4 address range, the remaining
pool of unallocated IPv4 addresses is below 30%. Recent consumption
rates are over 7% of the total IPv4 space per year. This run rate
leaves about 4 years to deplete the remaining unallocated pool.
>> Recent IETF list discussion would "debate" these numbers :)
Many private IPv4 networks take benefit from using the address space
defined in RFC 1918 to enlarge the available addressing space for
their private network, and at the same time reduce their need for
globally routable addresses. This type of local control of address
resources allow a clean and hierarchical addressing structure in the
network.
>> But v6 addressing for the enterprise is a /48 (in effect a Class A
of v4 address space, but with 2^64 hosts per subnet not 2^8).
>> With v6, you are far less likely to need to go back to ask for more
address space (with the paperwork that goes with that).
>> With v6, you don't have to resize subnets to use v4 address space
efficiently; an enterprise today may have a mix of /28 - /23 size
subnets for example, and may shrink/grow these as their network
user base/etc changes. In v6, it's all /64.
Another benefit is due to the usage of independent addresses on
majority of the network infrastructure there is an increased ability
to change provider with less operational difficulties.
>> This is a BIG plus for v4 today; no PI addressing in v6.
2.6.1 Medium/large private networks
Under this category fall the majority of private enterprise networks.
Many of these networks have one or more exit points to the Internet.
There are several reasons why NAT be be used in such a network. For
>> "be be" -> "may be"
the ISP there is no need to import the IPv4 address range from the
remote end-customer, which facilitates IPv4 address summarization.
The customer can use a larger IPv4 address range (probably with
less-administrative overhead) by the use of RFC 1918 and NAT. The
customer also reduces the overhead in changing to a new ISP, because
the addresses assigned to devices behind the NAT do not need to be
changed when the customer is assigned a different address by a new
ISP. Finally, the customer can provide privacy about its hosts and
the topology of its internal network if the internal addresses are
mapped through NAT.
>> So be more explicit and say "using NAT avoids the need for network
renumbering" and that "NAT can help support IPv4 site multihoming"
(though of course both solutions have restrictions and come at a
price) You do mention this further down, I note,
2.6.3 Single user connection
This group identifies the users which are connected via a single IPv4
address and use a single piece of equipment (PC, PDA, etc.). This
user may get an ambiguous IPv4 address from the service provider
which is based on RFC 1918. If ambiguous addressing is utilized, the
service provider will execute NAT on the allocated IPv4 address for
global Internet connectivity. This also limits the internet
capability of the equipment to being mainly a receiver of Internet
data, and makes it quite hard for the equipment to become a world
wide internet server (i.e. HTTP, FTP, etc.) due to the stateful
operation of the NAT equipment.
>> Or you have a SOHO user with one NAT device (e.g. cable modem) and
only one home PC. That's different to receiving a private v4
address that is NATed higher up the ISP network.
>> Also in Section 3, maybe mention that NAT is often not a customer
choice; it's frequently imposed by the ISP, or deployed because the
organisation outsourced its IT.
>> Is there an (obvious) new subsection for the case where the deploying
network for some reason feels it is unable to get enough global v4
address space, or the scenario is one where the number of attaching
nodes is unknown (e.g. a WLAN provision at a conference or hotel?)
3. Description of the IPv6 tools
This section describes several features that can be used to provide
the protection features associated with IPv4 NAT.
3.1 Privacy addresses (RFC 3041)
There is nothing that prevents a DHCP server from running RFC 3041
for any new MAC it hears, then remembering that for future queries.
This would allow using them in DNS for registered services since the
assumption would be a persistent value that minimizes DNS churn.
>> Any comment on the RFC3041-considered-harmful viewpoint here?
>> 3041 is very like v4 NAT in that 3041 doesn't protect the subnet ID
just as NAT doesn't protect the v4 global address used.
3.2 Unique Local Addresses
A unique local address (ULA) is an IPv6 unicast address format that
is globally unique and is intended for local communications [12].
These are expected NOT to be routed on the global Internet. They are
routable inside of a more limited area defined by a local network
administrator.
>> Note also draft-ietf-ipv6-ula-central-00, i.e. the ULA itself may
not be unique, whereas the centrally assigned prefixes should be.
For sites looking to merge without use of NAT, the central method
would give a greater assurance of no clash.
3.4 Untraceable IPv6 addresses
These are globally routable IPv6 addresses which can be randomly and
dynamically assigned to IPv6 devices and are globally aggregatable
addresses assigned to the local network by either a registry or
connecting ISP. The random assignment has as purpose to confuse the
outside world on the structure of the local network, while for the
local network the location of the randomly assigned IPv6 address is
known and connectivity inside the local network can exist. The goal
is to create a network infrastructure which appears from external
networks with an unpredictable structure, to avoid malicious events
to happen to the local network. When using untraceable IPv6
addresses, it may be that two apparently sequential addresses are
reachable on very different parts of the local network instead of
belonging to the same subnet next to each other.
>> Is there a reference to this? I'm not sure how this would actually
be implemented, or of the drawbacks of doing so.
>> Maybe "infinitely" sized subnets are an IPv6 "tool", in that a
subnet can absorb any number of hosts (in theory at least) without
subnet resizing or needing to NAT (if the network had a Class C v4
and might have more than 253 nodes attaching simultaneously).
>> Related is the issue of dynamic vs static address allocation; does
the same node get the same IP address when attaching each time, or
to conserve (v4) address space is the address dynamic? If a
network has a Class C v4 and has 1,000 users of whom only 100 may
be attached at any one time, in v4 you need dynamic addressing,
in v6 you don't.
4.1 Simple gateway between Internet and internal network
The connection creation towards the global Internet hosts/systems
will always happen with global IPv6 addresses. An enterprise will
typically receive a global IPv6 address prefix from his connecting
IPv6 Service Provider.
>> "his" -> "its"
4.2 IPv6 and Simple security
The vulnerability of an IPv6 host is similar as for an IPv4 host
directly connected towards the Internet, and firewall and IDS systems
are recommended. However, with IPv6, the following protections are
available without the use of NAT:
1. Short lifetimes on privacy extension suffixes reduce the attack
profile since the node will not respond to the address once the
address is no longer valid.
>> Important because with port-scanning very hard to do in v6, attackers
will need to gather target addresses from various server log files,
and then try these.
2. IPsec is a mandatory service for IPv6 implementations. IPsec
functions to prevent session hijacking, prevent content
tampering, and optionally masks the packet contents. While IPsec
might be available in IPv4 implementations, deployment in NAT
environments either breaks the protocol or requires complex
helper services with limited functionality.
>> Or significant compromises in trust.
3. The size of the typical subnet ::/64 will make a network ping
sweep and resulting port-scan virtually impossible due to the
Van de Velde, et al. Expires April 12, 2005 [Page 11]
Internet-Draft IPv6 Network Architecture Protection October 2004
amount of possible combinations available
>> See the port-scanning draft :)
This simple rule would create similar protection and security holes
the typical IPv4 NAT device will offer and may for example be enabled
by default on all broadband edge-routers. but with that difference
that the security caveats will be documented, and may hence be
removed with the next revision of the rule. The goal is that every
iteration, the IPv6 internet will become more secure for the
oblivious users.
>> The snag is configuring this in home networking scenarios (for example)
where today NAT "does the job"; as we require network access into the
home, how do we let Joe User say "my PDA can access my home DVR?".
unrealistic) pings to map the network, and virus/worm propagation
will be thwarted in the process At full rate 40Gbps (400 times the
typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
link) it takes over 5000 years to scan a single 64 bit space.
>> Again, see the port-scanning draft. You may find other notes worth
reusing in there.
4.4 Privacy and topology hiding using IPv6
By using untraceable addresses, it is possible to only allocate
certain parts of the internal network with global prefixes, while
other, private network parts do not have global prefixes and remain
totally cut off from the outside. If an edge firewall is used (which
is strongly suggested) a traffic policy can be implemented as today,
based on various filtering and inspection rules. (Older techniques
such as application level proxies and SOCKS also remain available.)
>> Worth mentioning (two-faced) DNS issues here?
If there is need to mask the internal structure towards the external
IPv6 internet, then the usage of 'Untraceable' addresses may be used.
These addresses will be derived from a local pool, and may be
assigned to those hosts for which topology masking is required or
which want to reach the IPv6 Internet or other external networks.
>> I think a separate I-D on "untraceable" addresses might be useful?
The technology to assign these addresses to the hosts could be based
on DHCPv6. To complement the 'Untraceable' addresses it is needed to
have at least awareness of the IPv6 address location when routing an
IPv6 packet through the internal network. This could be achieved by
'route-injection' in the network infrastructure. This
route-injection could be done based on ::/128 host-routes to each
device that wants to connect to the Internet.
>> I think you make a good point about scalability; need to have some
clearer idea of the tradeoffs here? (or in the separate I-D)
4.6.2 small private networks
The category describes those networks which only have only few
routers in the topology, and have a single network egress point.
These networks are also known as SOHO (Small Office/Home Office)
networks. Typically these networks don't have dedicated Network
Operation Center (NOC) and are using either a dial-up connection or
broadband access..
>> Most SOHO networks are single (access) router networks?
4.6.4 ISP/Carrier customer networks
This group refers to the actual service providers that are providing
the IP access. They tend to have three separate IP domains that they
support. For the first they fall into the Medium/large private
networks category (above) for their own internal networks, LANs etc.
and will be able to use the same solutions as above. The second is
their Operations network which addresses their backbone and access
switches, and other hardware, this is separate for both engineering
reasons as well as simplicity in managing the security of the
backbone, for this it is again possible to configure a single range
of addresses with the defined local scope defined in order to prevent
these from being accessed from the public network. The third is the
IP addresses (single or blocks) that they assign to customers. These
can be registered addresses (usually given to category a and b and
sometimes c) or can from a pool of RFC 1918 addresses used with NAT
for single user connections. Therefore they can actually have two
different NAT domains that are not connected (internal LAN and single
user customers) again this will be resolved by the large availability
of addresses and the procedures mentioned above.
>> So the main gain is simplified network management for the operator?
Or something else? Might be useful to make it clear.
4.7 Multihoming and renumbering
The IPv6 address space allocated by the ISP will be dependent upon
the connecting Service provider. This may result in a renumbering
effort if the enterprise changes from Service Provider. To keep the
>> "from" -> "its"
impact on the gateway when changing ISP to a zero human touch
environment, DHCPv6 Prefix Delegation [10] can be used.
>> You might want to cite Fred's draft here if you don't already, and
also draft-chown-v6ops-renumber-thinkabout-00. One specific
scenario to add here for renumbering might be network mergers?
5. Additional benefits due to Native IPv6 and universal unique
addressing
Is all of the material in this section, specifically the material
that does not directly address the "advantages" of IPv4 NAT,
necessary?
>> It is useful to document somewhere; perhaps split into two sections,
one in poker terms that "sees" IPv4 NAT, and one that raises the bet
with IPv6?
5.1 Universal any-to-any connectivity
One of the original design points of the Internet was any-to-any
connectivity. The dramatic growth of Internet connected systems
coupled with the limited address space of the IPv4 protocol spawned
address conservation techniques. NAT was introduced as a tool to
reduce demand on the limited IPv4 address pool, but the side effect
of the NAT technology was to remove the any-to-any connectivity
capability. By removing the need for address conservation (and
therefore NAT), IPv6 returns the any-to-any connectivity model and
removes the limitations on application developers. With the freedom
to innovate unconstrained by NAT traversal efforts, developers will
be able to focus on new advanced network services (i.e. peer-to-peer
applications, IPv6 embedded IPsec communication between two
communicating devices, instant messaging, Internet telephony, etc..)
rather than focusing on discovering and traversing the increasingly
complex NAT environment.
>> There are some good "transparency" type RFCs from Brian and others
that could be cited here. 2775 springs to mind. Also RFC on
implications of using NAT - 2993 I think.
5.2 Auto-configuration
IPv6 offers a scalable approach to minimizing human interaction and
device configuration. Whereas IPv4 implementations require touching
each end system to indicate the use of DHCP vs. a static address and
management of a server with the pool size large enough for the
potential number of connected devices, IPv6 uses an indication from
the router to instruct the end systems to use DHCP or the stateless
auto configuration approach supporting a virtually limitless number
of devices on the subnet. This minimizes the number of systems that
require human interaction as well as improves consistency between all
the systems on a subnet. In the case that there is no router to
provide this indication, an address for use on the local link only
will be derived from the interface media layer address.
>> Not sure about this. Most OSes will do DHCP(v4) by default today,
when connecting. So "autoconfiguration" is there, but it requires
DHCP to be set up somewhere by the "provider". How widely used
is the IPv4 link-local equivalent under 169. - seems to be mainly
a Microsoft implemented mechanism?
5.3 Native Multicast services
Multicast services in IPv4 were severely restricted by the limited
address space available to use for group assignments and an implicit
locally defined range for group membership. IPv6 multicast corrects
this situation by embedding explicit scope indications as well as
expanding to 4 billion groups per scope. In the source specific
multicast case, this is further expanded to 4 billion groups per
scope per subnet by embedding the 64 bits of subnet identifier into
the multicast address.
IPv6 allows also for innovative usage of the IPv6 address length, and
makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
directly in the IPv6 multicast address when using ASM multicast.
this is not possible with limited size of the IPv4 address.
>> Cite Pekka's work on this?
>> Also make a comment about SSM and IPv6? There seems to be a strong
feeling that IPv6 is an opportunity to get SSM deployed more widely
with its more streamlined architecture.
5.4 Increased security protection
The security protection offered by native IPv6 technology is more
advanced as with IPv4 technology. There are various transport
>> "as with" -> "than"?
mechanisms enhanced to allow a network to operate more secure with
less performance impact:
>> "secure" -> "securely"
o On a local network, any user will have more security awareness.
This awareness will motivate the usage of simple firewall
applications/devices to be inserted on the border between the
external network and the local (or home network).
>> I don't think users will be more security aware with IPv6, if they
even know they're using IPv6. I think with growing use of shared
hotspots etc we'll see growing awareness of personal firewalls in
general.
o The usage of private address-space in IPv6 still provides with
>> "is now provided by"
Unique Local Addresses, which will avoid conflict situations when
joining networks and securing the internal communication on a
>> "joining" -> "merging"
local network infrastructure due to simpler traffic filtering
policy
5.5 Mobility
Anytime, anywhere, universal access requires mIPv6 services in
>> "MIPv6"
support of mobile nodes. While a Home Agent is required for initial
connection establishment in either protocol version, IPv6 mobile
nodes are able to optimize the path between them using the mIPv6
>> "MIPv6"
option header while IPv4 mobile nodes are required to triangle route
all packets. In general terms this will minimize the network
resources used and maximize the quality of the communication
>> eg. very useful when two mobile nodes in same WLAN with low bandwidth
uplink what to share data, to avoid the data passing over the uplink.
5.6 Merging networks
With the usage of IPv6 the addressing overlap will not exist because
of the existence of the Unique Local Address usage for private and
local addressing.
>> As per above, note the difference between the two variants of ULA, one
centrally assigned.
5.7 Community of interest
Although some Internet-enabled devices will function as fully-fledged
Internet hosts, it is believed that many will be operated in a highly
restricted manner functioning largely or entirely within a Community
of Interest. By Community of Interest we mean a collection of hosts
that are logically part of a group reflecting their ownership or
function. Typically, members of a Community of Interest need to
communicate within the community but should not be generally
accessible on the Internet. They want the benefits of the
connectivity provided by the Internet, but do not want to be exposed
to the rest of the world. This functionality will be available
through the usage of NAP and native IPv6 dataflows, without any
stateful device in the middle.
>> Also maybe talk about virtual organisation networks built on the fly?
Very difficult to do in IPv4+NAT scenarios. The nodes may also
take part in other communications in general.
6. IPv6 gap analysis
6.3 Minimal traceability of privacy addresses
Privacy addresses (RFC 3041) may certainly be used within the
enterprise to limit the traceability of external traffic flows, but
they would still reveal the subnet address bits. To eliminate this,
some combination of privacy addresses with the previous two points is
required, and this work remains to be done.
>> The use of privacy addresses is also itself generally detectable.
6.4 Renumbering procedure
Documentation of site renumbering procedures [11] should be
completed. It should also be noticed that ULAs will help here too,
since a change of ISP prefix will only affect hosts that need an
externally routeable address as well as a ULA.
>> Also draft-chown-v6ops-renumber-thinkabout-00. Are there downsides
to using ULAs? If so, these are not described in this text. e.g. it
requires all nodes to implement address selection as desired (favour
ULA src for ULA dst, global src for global dst, etc).
6.6 Untraceable addresses
The details of the untraceable addresses, along with any associated
mechanisms such as route injection, must be worked out and specified.
>> A new I-D on this would be good.
>> What about a set of recommendations for a site? Like "use ULAs if
you want feature X", or is this just implied already?