[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last call on draft-ietf-v6ops-nap-01.txt
Some more comments on this draft. Apologies for the lateness.
--
Tim/::1
1. Introduction
Although there are many perceived benefits to Network Address
Translation (NAT), its primary benefit of "amplifying" available
address space is not needed in IPv6. The serious disadvantages of
ambiguous "private" address space and of Network Address Translation
(NAT) [1][5] have been well documented [4][6]. However, given its
wide market acceptance NAT undoubtedly 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. 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 IPv6. The use of the facilities
from IPv6 described in this document avoids the negative impacts of
translation and may be described as Network Architecture Protection
(NAP).
>> Does it explain why IPv6 NAT is not needed also?
>> Add reference to rfc2775 maybe?
As far as security and privacy is concerned, this document considers
how to mitigate a number of threats. Some are obviously external,
such as having a hacker trying to penetrate your network, or having a
worm infected machine outside your network trying to attack it. Some
are local such as a disgruntled employee disrupting business
operations, or the unintentional negligence of a user downloading
some malware which then proceeds to attack any device on the LAN.
Some may be embedded such as having some firmware in a domestic
appliance "call home" to its manufacturer without the user's consent.
>> Note the threats that are user-initiated (e.g. web browser download) are
>> different to those that are 'pushed' into a site. IPv6 does not really
>> help the former, but may help against the latter, and also the internal
>> spread of such threats (e.g. worms that search for hosts on a subnet/link
>> to infect).
IPv6 Network Architecture Protection can be summarized in the
following table. It presents the marketed functions of NAT with a
cross-reference of how those are delivered in both the IPv4 and IPv6
environments.
Function IPv4 IPv6
+------------------+-----------------------+-----------------------+
| Simple Gateway | DHCP - single | DHCP-PD - arbitrary |
| as default router| address upstream | length customer |
| and address pool | DHCP - limited | prefix upstream |
| manager | number of individual | SLAAC via RA |
| | devices downstream | downstream |
| | see section 2.1 | see section 4.1 |
>> Why does DHCP limit the number of downstream devices? Why not use
>> DHCP with IPv6?
+------------------|-----------------------|-----------------------+
| Topology hiding | NAT transforms | Untraceable addresses|
| | subnet bits in the | using IGP host routes|
| | address | /or MIPv6 tunnels for|
| | | stationary systems |
| | see section 2.4 | see section 4.4 |
>> Host route scalability limited though?
+------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & ULA |
| Autonomy | | |
| | see section 2.5 | see section 4.5 |
>> Or do we encourage all sites to use 3177 addresses even if not connected?
+------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 340,282,366,920,938, |
| Pool | | 463,463,374,607,431, |
| Conservation | | 768,211,456 |
| | | (3.4*10^38) addresses|
| | see section 2.6 | see section 4.6 |
>> 2^128 addresses doesn't help if sites get given too big a prefix ;)
>> What about internal site benefits? Like resilience to 'ping and infect'
>> type worms on a subnet/link do to link size, or port scanning reslience,
>> for which IPv4 has no 'equivalent'? Add these to the table and refer
>> to text? Should all text sections appear in the summary table?
2.1 Simple gateway between Internet and internal network
A NAT device can connect a private network with any kind of address
(ambiguous [RFC 1918] or global registered address) towards the
Internet. The address space of the private network can be built from
globally unique addresses, from ambiguous address space or from both
simultaneously. Without specific configuration from public to
private, the NAT device enables access between the client side of an
application in the private network with the server side in the public
Internet.
>> Explain somewhere what is meant by 'ambiguous address space'?
Additionally, thanks to successful marketing campaigns it is
perceived by end users that their equipment is protected from the bad
elements and attackers on the public IPv4 Internet.
2.2 Simple security due to stateful filter implementation
It is frequently believed that through its session-oriented
operation, NAT puts in an extra barrier to keep the private network
protected from evil outside influences. Since a NAT device typically
keeps state only for individual sessions, attackers, worms, etc.
cannot exploit this state to attack a host in general and on any
port. This benefit may be partially real, however, experienced
hackers are well aware of NAT devices and are very familiar with
private address space, and have devised methods of attack (such as
trojan horses) that readily penetrate NAT boundaries. For these
reasons the sense of security provided by NAT are actually false.
>> But aren't these 'trojans' applicable to IPv6 systems too? Is NAT
>> a special case?
In some cases, NAT operators (including domestic users) may be
obliged to configure quite complex port mapping rules to allow
external access to local applications such as a multi-player game or
web servers. In this case the NAT actually adds management
complexity compared to a simple router. In situations where 2 or
more devices need to host the same application this complexity shifts
from difficult to impossible.
>> And the chances for misconfiguration grow. Though for every such
>> mapping you are likely? to need an equivalent firewall rule in an
>> IPv6 network?
2.4 Privacy and topology hiding
There is a similarity with privacy based on application level
proxies. When using an application level gateway for browsing the
web for example, the 'privacy' of a web user can be provided by
masking the true identity of the original web user towards the
outside world (although the details of what is - or is not - logged
at the NAT/proxy will be different).
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. Scanning for IPv6 can be
much harder in comparison with IPv4 as described in [17]
>> There's a new I-D now on how to best configure IPv6 access devices to
>> ensure ICMP filtering is done properly (e.g. doesn't break PMTU
>> discovery) - cite it somewhere?
2.5 Independent control of addressing in a private network
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 allows a clean and hierarchical addressing structure in the
network.
>> But in some cases even 16M 'net 10' addresses are not enough?
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.
>> Only if the site is generally client devices, rather than servers;
>> in the latter case you generally wouldn't use NAT though.
2.6 Global address pool conservation
Due to the ongoing depletion of the IPv4 address range, the remaining
pool of unallocated IPv4 addresses is below 30%. While mathematical
models based on historical IPv4 prefix consumption periodically
attempt to predict the future exhaustion date of the IPv4 address
pool, a direct result of this continuous resource consumption is that
the administrative overhead for acquiring globally unique IPv4
addresses will continue increasing in direct response to tightening
allocation policies. In response to the increasing administrative
overhead many Internet Service Providers (ISPs) have already resorted
to the ambiguous addresses defined in RFC 1918 behind a NAT for the
various services they provide as well as connections for their end
customers. In turn this has restricted the number of and types of
applications that can be deployed by these ISPs and their customers.
Forced into this limiting situation such customers can rightly claim
that despite the optimistic predictions of mathematical models the
global pool of IPv4 addresses is effectively already exhausted.
>> Note RFC1918 may be used for end customers, or for ISP infrastructure,
>> sometimes for one, not the other. Managing two sets of RFC1918
>> networks is more complex. Some ISPs seem to be considering IPv6 for
>> their infrastructure management?
2.7 Multihoming and renumbering with NAT
This solution may be sufficient for some networks; however when the
merging networks were already using address translation it will
create huge problems due to admistrative difficulties of the merged
address space.
>> Especially since they'll often both be using 10.0.0.* for example.
3.1 Privacy addresses (RFC 3041)
While the primary implementation and source of randomized RFC 3041
addresses is expected to be from end systems running stateless
autoconfiguration, there is nothing that prevents a DHCP server from
running the RFC 3041 algorithm for any new IEEE identifier it hears,
then remembering that for future queries. This would allow using
them in DNS for registered services since the assumption of a server
based deployment would be a persistent value that minimizes DNS
churn. A DHCP based deployment would also allow for local policy to
periodically change the entire collection of end device addresses
while maintaining some degree of central knowledge and control over
which addresses should be in use at any point in time.
>> Yes, DHCPv6 supports allocating privacy addresses. Note 3041 is
being updated at this time. Many sites will NOT want to have such
addresses used (due to management issues) so would probably run
full DHCPv6 for address management.
3.2 Unique Local Addresses
Local network and application services stability during periods of
intermittent connectivity between one or more providers requires
address management autonomy. Such autonomy in a single routing
prefix environment would lead to massive expansion of the global
routing tables, so IPv6 provides for simultaneous use of multiple
prefixes. The Unique Local Address prefix (ULA) [12] has been set
aside for use in local communications. The ULA address prefix for
any network is routable over a locally defined collection of routers.
These prefixes are NOT to be routed on the public global Internet as
that would have a serious negative impact on global routing.
>> Well, they can be routed anywhere you can convince ISPs to do so for
you... :)
ULAs have the following characteristics:
o Globally unique prefix
* Allows networks to be combined or privately interconnected
without creating any address conflicts or requiring renumbering
of interfaces using these prefixes
* If accidentally leaked outside of a network via routing or DNS,
there is no conflict with any other addresses
o ISP independent and can be used for communications inside of a
network without having any permanent or intermittent Internet
connectivity
>> delete 'or intermittent'
o Well known prefix to allow for easy filtering at network
boundaries
o In practice, applications may treat these addresses like global
scoped addresses
>> They should treat them as globals, because they have *global* scope, but
the reality is more complex :(
3.4 Untraceable IPv6 addresses
These should be globally routable IPv6 addresses which can be
randomly and independently assigned to IPv6 devices.
The random assignment has as purpose to confuse the outside world on
the structure of the local network. However for the local network
there is a correlation between the location of the device and the
untraceable IPv6 address. This correlation could be done by
generating IPv6 host route entries or by utilizing an aggregation
device like a Mobile IPv6 Home Agent.
>> I really don't like this text being in the draft.
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. A proxy may be used for certain applications, but
has the caveat that the end to end transparancy is broken. However,
with IPv6, the following protections are available without the use of
NAT while maintaining end-to-end reachability:
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.
>> Is 'suffix' the right word?
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 efficiency.
>> Availability of AH and ESP functionality is 'mandated', usage is not.
4.3 User/Application tracking
IPv6 enables the collection of information about data flows. Due to
the fact that all addresses used for Internet and intra-/inter- site
communication are unique, it is possible for an enterprise or ISP to
get very detailed information on any communication exchange between
two or more devices. This enhances the capability of data-flow
tracking for security audits compared with IPv4 NAT, because in IPv6
a flow between a sender and receiver will always be uniquely
identified due to the unique IPv6 source and destination addresses.
>> So long as 3041 isn't used.
4.4 Privacy and topology hiding using IPv6
When a network manager also wishes to conceal the internal IPv6
topology, by using explicit host routes it is possible to locate
nodes on one segment while they appear externally to be on another.
An alternative method to hide the internal topology would be to use
Mobile IPv6 internally without route optimization where the public
facing addresses are consolidated on an edge Home Agent (HA), then
use MIPv6 in bidirectional tunnel mode between the HA and topology
masked node using the ULA as a COA. This truly masks the internal
topology as all nodes with global access appear to share a common
subnet. There is no reason that rack mounted devices couldn't be
considered mobile nodes to mask the internal topology. It looks
equivalent to running a VPN to a central server, however it does not
involve any encryption or significant overhead.
>> Again, I don't like this. The 'cost' for the gain is very, very high.
4.5 Independent control of addressing in a private network
IPv6 provides sufficient space to completely avoid the need for
overlapping address space,
340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total
possible addresses. As previously discussed, the serious
disadvantages of ambiguous address space have been well documented,
and with sufficient space there is no need to continue the
increasingly aggressive conservation practices that are necessary
with IPv4. While IPv6 allocation policies and ISP business practice
will continue to evolve, the recommendations in RFC 3177 are based on
the technical potential of the vast IPv6 address space. That
document demonstrates that there is no resource limitation which will
lead to the IPv4 practice of ambiguous space behind a NAT. As an
example of the direct contrast, many expansion oriented IPv6
deployment scenarios result in multiple IPv6 addresses per device, as
opposed to the IPv4 constricting scenarios of multiple devices
sharing a scarce global address.
>> Note RFC3177 is under -bis revision at the moment.
4.7 Multihoming and renumbering
Multihoming and renumbering remain technically challenging with IPv6
(see the Gap Analysis below). However, IPv6 was designed to allow
sites and hosts to run with several simultaneous CIDR-like prefixes
and thus with several simultaneous ISPs. An address selection
mechanism [9] is specified so that hosts will behave consistently
when several addresses are simultaneously valid. The fundamental
difficulty that IPv4 has in this regard therefore does not apply to
IPv6. IPv6 sites can and do run today with multiple ISPs active, and
Van de Velde, et al. Expires December 3, 2005 [Page 16]
Internet-Draft IPv6 Network Architecture Protection june 2005
the processes for adding and removing active prefixes at a site have
been documented [11] and [18].
>> IPv4 has no lifetime or deprecation indicators like IPv6. With IPv6
multiaddressing is likely to be common.
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 network changes from Service Provider. When changing
ISPs or ISPs readjusting their addressing pool, DHCP-PD [10] can be
used as the zero-touch external mechanism for prefix change in
conjunction with a ULA prefix for internal connection stability.
With appropriate management of the lifetime values and overlap of the
external prefixes, a smooth make-before-break transition is possible
as existing communications will continue on the old prefix as long as
it remains valid, while any new communications will use the new
prefix.
>> I think the renumbering tests we did show that ULAs are not necessary.
ULA also adds 'cost' in terms of complexity, since they are *global*
scope addresses now.
5. Case Studies
It is possible to divide the type of networks in different
categories. This can be done on various criteria. The criteria used
within this document are based on the number of components or
connections. For each of these category of networks we can use IPv6
Network Architecture Protection to achieve a secure and flexible
infrastructure, which provides an enhanced network functionality in
comparison with the usage of address translation.
o Medium/large private networks (typically >10 connections)
o Small private networks (typically 1 to 10 connections)
o Single user connection (typically 1 connection)
o ISP/Carrier customer networks
>> You mean devices/nodes, or connections as in network links offsite?
>> Our site has 20,000 nodes, and 1 connection. It is not 'small private'.
The summarization benefit for the ISP is happening based on the IPv6
allocation rules. This means that the ISP will provide the
enterprise with an IPv6 address-range (typically a one or multiple
range(s) of '/48') from its RIR assigned IPv6 address-space. The
goal of this allocation mechanism is to decrease the total amount of
entries in the internet routing table.
>> summarization -> aggregation?
To mask the identity of a user on a network of this type, the usage
of IPv6 privacy extensions may be advised. This technique is useful
when an external element wants to track and collect all information
sent and received by a certain host with known IPv6 address. Privacy
extensions add a random factor to the host part of an IPv6 address
and will make it very hard for an external element to keep
correlating the IPv6 address to a host on the inside network. The
usage of IPv6 privacy extensions does not mask the internal network
structure of an enterprise network.
>> And the ISP just tracks prefix usage for billing/etc?
If there is need to mask the internal structure towards the external
IPv6 internet, then some form 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.
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 using an untraceable address.
>> Again, yuk. Do we need this?
5.2 Small private networks
o DHCPv6 Prefix-Delegation
o ISP provides a static IPv6 address-range
For the DHCPv6-PD solution, a dynamic address allocation approach
>> dynamic, or automatic? I hope it's automatic and static.
>> DHCP-PD != dynamic/changing allocations ?
is chosen. By means of the enhanced DHCPv6 protocol it is possible
to have the ISP push down an IPv6 prefix range automatically towards
the small private network and populate all interfaces in that small
private network dynamically. This reduces the burden for
administrative overhead because everything happens automatically.
For the static configuration the mechanisms used could be the
same as for the medium/large enterprises. Typically the need for
masking the topology will not be of high priority for these users,
and the usage of IPv6 privacy extensions could be sufficient.
>> A manual rather than static setup?
For both alternatives the ISP has the unrestricted capability for
summarization of its RIR allocated IPv6 prefix, while the small
>> summarization -> aggregation?
While a full prefix is expected to be the primary deployment model
there may be cases where the ISP provides a single IPv6 address for
use on a single piece of equipment (PC, PDA, etc.). This is expected
to be rare though, because in the IPv6 world the assumption is that
there is an unrestricted availability of a large amount of globally
routable and unique address space. If scarcity was the motivation
with IPv4 to provide RFC 1918 addresses, in this environment the ISP
will not be motivated to allocate private addresses towards the
single user connection because there are enough global addresses
available at essentially the same cost. Also if the single device
wants to mask its identity to the called party or its attack profile
over a short time window it will need to enable IPv6 privacy
extensions, which in turn leads to the need for a minimum allocation
of a /64 prefix rather than a single address.
>> Agree we should emphasise a minimum /64.
5.3 Single user connection
In IPv6 world the assumption is that there is unrestricted
availability of a large amount of globally routable and unique IPv6
addresses. The ISP will not be motivated to allocate private
addresses towards the single user connection because he has enough
global addresses available, if scarcity was the motivation with IPv4
to provide RFC 1918 addresses. If the single user wants to mask his
identity, he may choose to enable IPv6 privacy extensions.
>> Can he, if the ISP may try to enforce the use of a single address?
5.4 ISP/Carrier customer networks
When looking in chapter 2.3 of RFC3314 'Recommendations for
IPv6 in 3GPP Standards' [14] it is found that the IPv6 WG recommends
that one or more /64 prefixes should be assigned to each primary PDP
context. This will allow sufficient address space for a 3GPP-
attached node to allocate privacy addresses and/or route to a multi-
link subnet, and will discourage the use of NAT within 3GPP-attached
devices.
>> I guess an ISP/carrier may use RFC1918 addresses for its infrastructure
>> independently of assignemnts to end customers.
6. IPv6 gap analysis
Like IPv4 and any major standards effort, IPv6 standardization
work continues as deployments are ongoing. This section discusses
several topics for which additional standardization, or documentation
of best practice, is required to fully realize the benefits of NAP.
None of these items are show-stoppers for immediate usage of NAP in
roles where there are no current gaps.
>> Maybe this should all be punted to a separate draft?? It would be
>> nice to see NAP as a long-lived document, and this section will be
>> quite fluid? Or call 'Recommendations for further work'? Hmmm.
Other comments:
>> Maybe mention that in the 'real world' IPv4 NAT + IPv6 globals are likely
>> to run dual-stack. What is the implication on security there? How can
>> firewalls/CPE equipment be configured consistently between the two?