[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Review of draft-ietf-v6ops-nap-02.txt
FYI. Margaret's original message seems to have not made it to v6ops,
or at least through it to me and reportedly several of you.
-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com] On Behalf Of
Margaret Wasserman
Sent: Wednesday, May 24, 2006 7:06 PM
To: 'iesg@ietf.org'; 'v6ops@ops.ietf.org'
Subject: Review of draft-ietf-v6ops-nap-02.txt
Hi All,
I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number of serious
issues with the document. I realize that the Last Calls have already
completed and that this document is on the agenda for this week's IESG
telechat, but I consider these issues to be serious enough that they are
worth raising as late objections.
I think that there is a serious problem with the way this document
describes
existing NAT technology. There are significant issues with the tone
of this
document, which is arrogant and argumentative. I also believe that the
document contains several factual mistakes and some potentially damaging
recommendations. In addition to resolving my review comments, I would
suggest that the document shepherd request a technical review from
members
of the Transport area who focus on NAT-related technologies.
While there are some strong technical points in this document, I
think that
they are severely weakened by the length of the document and the
level of
IPv6 marketing hype included in a document that is simultaneously
bashing
NAT providers for exactly this sort of behaviour. Little of this hype,
including the entire appendix, is actually operational advice of any
kind,
and I don't know why the IETF would want to publish it. There are
already
existing groups that market IPv6, and I think that it is outside the
scope
of the IETF to do so.
The authors also seem to have inserted quite a bit of their own
religion,
and I think that there are large parts of this document that do not even
come close to expressing IETF consensus on various topics like NAT
features,
the usefulness of firewalls, appropriate use of the IGP routing
practices,
etc. It seems unlikely that this document has received adequate
review from
people in these areas.
In other words, I think that some of the contents of this document
and the
current editorial style make it unsuitable for publication as an RFC.
Specific comments are included below, along with the document exerpts
that
they refer to.
Margaret
---
Abstract
Although there are many perceived benefits to Network Address
Translation (NAT), its primary benefit of "amplifying" available
address space is not needed in IPv6. In addition to NAT's many
serious disadvantages, there is a perception that other benefits
exist, such as a variety of management and security attributes that
could be useful for an Internet Protocol site. IPv6 does not
support
NAT by design and this document shows how Network Architecture
Protection (NAP) using IPv6 can provide the same or more benefits
without the need for NAT.
This abstract seems very slanted. I also think that it would be
incorrect
at this point to say that "amplifying" address space is the primary
benefit
of NATs, as many companies use them in spite of the fact that they have
plenty of address space available.
There are at least three other _real_ benefits of NAT boxes. While I
hold
with this document's position that these benefits can and should be
realized
in other ways in IPv6, I do not think it is factual or helpful to
argue that
they don't exist. Those benefits are:
(1) Avoiding the reliance of internal network number on externally
allocated
numbers. AKA not having to renumber when you change ISPs or when ISPs
change address allocation strategies.
(2) Hiding internal topology from external communicants.
(3) Avoiding the establishment of unauthorized inbound connections.
While this NAT side effect can also cause problems, it does provide
the real
benefits of a stateful firewall.
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
hat some connectivity and security concerns can only be solved by
using a NAT device or by using logically separated Local Area
Network
(LAN) address spaces. This document describes the reasons for
utilizing a NAT device in an IPv4 environment that are regularly
cited in marketing pronouncements. It then shows how these needs
can
be met without using NAT in an IPv6 network. Some of the IPv6
solutions offer advantages beyond the equivalent IPv4 NAT solution.
The use of the facilities from IPv6 described in this document
avoids
the negative impacts of address translation.
I don't understand, at all, the mentione of "marketing departments"
and "marketing pronouncements" in this section and think it should be
reworded to remove them and/or cite specific documents. There are real
reasons why people use NATs in IPv4, and there are better ways to do
those
things with IPv6. That's what we should say. The text in the above
paragraph is insulting, incorrect and very likely to get the network
administrator to stop reading before you can offer any advice on how to
set-up an IPv6 network.
2. Perceived Benefits of NAT and its Impact on IPv4
This section provides insight into the generally perceived benefits
of the use of IPv4 NAT as extolled by product marketing. The
goal of
Again with the "product marketing". Do the authors of this document
really
believe that these benefits do not exist? Does the IETF as a whole? I
think we should be somewhat embarrassed to publish this document as-is,
because it seems very naive and one-sided. This continues throughout
the
document, but I will not continue to mention it.
2.2. Simple Security due to Stateful Filter Implementation
A firewall doesn't fully secure a network, because many attacks come
from inside or are at a layer higher than the firewall can protect
against. In the final analysis, every system has to be responsible
for its own security, and every process running on a system has
to be
robust in the face of challenges like stack overflows etc. What a
firewall does is prevent a network administration from having to pay
for bandwidth to carry unauthorized traffic, and in so doing reduce
the probability of certain kinds of attacks across the protected
boundary.
This is the section where we are describing the benefits of NAT without
analyzing them. So, why is this sub-section here? It is clear that the
side effects of NAT can be used as one element of a system to protect
internal nodes. It is not sufficient to protect them from
everything, which
doesn't mean that it doesn't protect them against anything. Much of
this
section could appear to be an argument that firewalls of all kinds are
useless because of the existence of Trojan Horse-style attacks, which is
obviously false. Have any firewall experts been asked to review this
section? If not, I think you should ask someone like Steve Bellovin
to do
so.
2.3. User/Application tracking
Although NATs create temporary state for active sessions, in general
they 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 could in theory be done by
logging the network address translation details of the private and
the public addresses from the NAT device's state database.
The checking of this database is not always a simple task,
especially
if Port Address Translation is used. It also has an unstated
assumption that the administrative instance has a mapping between an
IPv4-address and a network element or user at all times, or the
administrator has a time-correlated list of the address/port
mappings.
I think that this document is arguing that User/Application tracking
is not
a benefit of NAT? If so, why is it even in this document?
2.4. Privacy and Topology Hiding
The goal of 'topology hiding' is to provide devices on the private
network with an identifier (IPv4 address) which an entity outside
the
network can use to communicate with or to reference the private
network devices in protocols but prevents the external entity making
a correlation between the topological location of the private device
and the address on the local network.
The above sentence does not parse (editorial).
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. When concealed behind a NAT it is impossible to
tell from the outside which member of a family, which customer of an
Internet cafe, or which employee of a company generated or
received a
particular packet. 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, usually known as 'device profiling'. At the same time a
NAT creates a smaller pool of addresses for a much more focused
point
of attack.
What does the last sentence mean? Give some sort of example or take
it out,
perhaps?
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 is intended to mislead the outside world about
the structure of the local network. However the local network needs
to maintain 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 indirection
device such as a Mobile IPv6 Home Agent.
Is not technically sound to advocate the dissemination of host routes
in the
IGP for infrastructure hiding. IGPs are not designed to scale well
for this
sort of use. It would be much more technically sound to advocate the
use of
L2 switching to avoid exposure of network topology at L3.
Besides, I thought the point of network address hiding (or one of
them), as
outlined above was to avoid the ability to identify different nodes by
address for port scanning purposes, not (merely) to avoid the ability to
tell what subnets they are on. The proposed technique doesn't seem to
address that issue at all.
With external connectivity the simple gateway could also use DHCP-PD
to acquire a routing prefix from the service provider for use when
connecting to the global Internet. End-system connections involving
other nodes on the global Internet will always use the global IPv6
addresses [9] derived from this prefix delegation. It should be
noted that the address selection policy table in end-systems
needs to
be correctly set up so that true global prefixes are distinguished
from ULAs and will be used for the source address in preference when
the destination is not a ULA.
Unless one takes steps to actively screw this up, a globally routable
destination address will always have a longest-prefix match with a
globally
routable source and a ULA will always have a longest-prefix match with a
ULA. So, the last sentence is completely unnecessary and somewhat
misleading.
The tricky part is making sure that the node uses the right
_destination_
address -- a ULA for local traffic and global address for non-local
traffic.
This will generally require the use of some type of split DNS, with ULAs
returned internally but not externally.
In the very simple case there is no explicit routing protocol and a
single default route is used out to the global Internet. A slightly
more complex case might involve local routing protocols, but with
the
entire local network sharing a common global prefix there would
still
not be a need for an external routing protocol as a default route
would continue to be consistent with the connectivity.
I don't understand this paragraph at all. What does it have to do with
ULAs? Also, the second half of this sentence doesn't make sense.
I'm not 100% sure what it means, but if it means what I think it
means, it
is wrong.
4.2. IPv6 and Simple Security
The vulnerability of an IPv6 host is similar to that of an IPv4 host
directly connected towards the Internet. The use of firewall and
Intrusion Detection Systems (IDS) is recommended. A proxy may be
used for certain applications, but with 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.
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.
IPsec performs exactly the same purposes in IPv4 as IPv6. I don't
know of
any stacks that implement IPsec for IPv6 and not for IPv4.
Also, it is not clear that end-to-end IPsec is fundamentally useful,
even
without the interference of a NAT box, as I believe that there needs
to be
some sort of binding to the upper layer protocol in order for IPsec to
provide these protections.
If you decide to keep this section, you should acknowledge that use
of the
IPv6 stateful firewall mechanisms advocated in bullet 3 will present
similar
obstacles to using IPsec.
3. The size of the address space of a typical subnet (64 bits of
IID) will make an effective network ping sweep and resulting
port-scan virtually impossible due to the number of possible
combinations available, provided that IIDs are essentially
randomly distributed across the available space.
IIDs will not be randomly distributed. They are based on EUI-64 IDs
which
are certainly not randomly distributed. In fact, on Ethernet 16 of the
64-bits will have a known value. Also, the numbering space for the
first
three bytes (24-bits) is not completely allocated and there is very
clearly
an unbalanced distribution in that space. The fact that companies
tend to
buy somewhat homogenous hardware can make it possible to guess which
three-byte combinations are most likely to be present within a given
company. So, the length of the IID offers nowhere near the level of
protection described above.
This protection is nullified if the attacker has no access to a
local connection. If an attacker has local access then he
could use ND [3] and ping6 to ff02::1 to detect local
neighbors. (Of course, a locally connected attacker has many
scanning options with IPv4 as well.) It is recommended for
site administrators to take [18] into consideration to achieve
the expected goal. This protection will also be nullified if
IIDs are configured in a group near the start of the IID space.
Assuming the network administrator is aware of [18] the increased
size of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. The intention of topology
probing is to identify a selection of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of address space, this means that an
attacker has to send out a simply unrealistic number of 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.
See my comments above about why this is not correct.
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.
Why is this mentioned in this document? Given this paragraph, I
think you
have perversely stated another benefit of NAT -- that my ISP cannot
effectively track this information on a per-machine basis.
Also, how is this consistent with the idea that IPv6 will use privacy
address for client communications?
There are two possible scenarios for the extreme situation when a
network manager also wishes to fully conceal the internal IPv6
topology.
o One could use explicit host routes and remove the correlation
between location and IPv6 address. This solution does however
show severe scalability issues.
Right. That is why we should not recommend it.
o The other technology to fully hide the internal topology would be
to use a tunneling mechanism. Mobile IPv6 without route
optimization is one example. In this example the public facing
addresses are indirected via an edge Home Agent (HA). This
indirection method truly masks the internal topology as all nodes
with global access appear to share a common prefix. The downside
of using this method is that it makes usage of middleware like a
Home Agent (HA).
This seems awfully complex and may present other problems, such as
brittleness and MTU/fragmentation issues.
What are the possible benefits of subnet hiding that could justify
this type
of solution?
There are other answers involving L2 bridging with VLANs for limiting
broadcast domains that are much more scalable and simpler than either of
these approaches.
4.5. Independent Control of Addressing in a Private Network
[...]
When using IPv6, the need to ask for more address space will become
far less likely due to the increased size of the subnets. These
subnets typically allow 2^64 addresses per subnet and an enterprise
will typically receive a /48 which allows segmentation into at least
2^16 different subnets.
The ongoing subnet size maintenance may become simpler when IPv6
technology is utilised. If IPv4 address space is optimised one has
to look periodically into the number of hosts on a segment and the
subnet size allocated to the segment; an enterprise today may have a
mix of /28 - /23 size subnets for example, and may shrink/grow these
as their network user base changes. For IPv6 all subnets have /64
prefixes.
I am not really sure what any of this has to do with anything, and it
isn't
entirely correct. The 64-bit IID is a hard limit in IPv6, but there
is no
hard limit that all sites will be allocated a /48.
4.6. Global Address Pool Conservation
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
The naivete of pointing out the number of possible IPv6 addresses
actually
hurts this argument. Because of the 64-bit IID and the IETF's
recommendations to allocate a /48 to home users, the address space
will be
much less densely used than in IPv4. Many people still feel that
there will
be enough address space that conservation is not needed, and there are
decent documents that you could cite that make that argument. This has
little or nothing to do with the number of possible addresses in IPv6,
though.
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
require the adoption of the IPv4 workaround 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 constriction of IPv4 scenarios where
multiple devices are forced to share a scarce global address.
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 [10] 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
the processes for adding and removing active prefixes at a site have
been documented [12] and [19].
To be balanced, you should at least say something here about the fact
that
end-user sites that currently have "swamp space" addresses in IPv4
may need
to move ot ISP-provided addresses in IPv6, thus increasing concerns
about
renumbering and multi-homing.
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. This
will provide the most dynamic masking, but will have a scalability
limitation, as an IGP is typically not designed to carry many
thousands of IPv6 prefixes. A large enterprise may have
thousands of
hosts willing to connect to the Internet. Less flexible masking
could be to have time-based IPv6 prefixes per link or subnet. This
may reduce the amount of route entries in the IGP by a significant
factor, but has as trade-off that masking is time and subnet based.
This whole "untraceable" address concept seems to be poorly thought-
out. I
am concerned that this document, while supposedly an informational
document
on existing IPv6 features is trying to specify a new IPv6 feature and
doing
it quite inadequately, IMO.
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.).
How does this differ from the "single user connection" case described in
5.3?
6.1. Subnet Topology Masking
There really is no functional gap here as a centrally assigned pool
of addresses in combination with host routes in the IGP is an
effective way to mask topology.
You discuss the scaling issues in your own document, so this seems to be
misleading.
6.4. Site Multihoming
This complex problem has never been completely solved for IPv4,
which
is exactly why NAT has been used as a partial solution. For IPv6,
after several years' work, the IETF has converged on an
architectural
approach intended with service restoration as initial aim [20].
Again, ULAs may help since they will provide stable addressing for
internal communications that are not affected by multihoming.
Depending on what benefits are expected from multihoming, the
capacity for
IPv6 to use more than one prefix per interface may help here, too.
Appendix A. Additional Benefits due to Native IPv6 and Universal Unique
Addressing
I am not really sure that including a "marketing brochure" regarding the
general benefits of IPv6 at the end of this document serves to make
it any
clearer.
The users of native IPv6 technology and global unique IPv6 addresses
have the potential to make use of the enhanced IPv6 capabilities, in
addition to the benefits offered by the IPv4 technology.
A.1. Universal Any-to-Any Aonnectivity
Connectivity, perhaps?
A.4. Increased Security Protection
The security protection offered by native IPv6 technology is more
advanced than IPv4 technology. There are various transport
mechanisms enhanced to allow a network to operate more securely with
less performance impact:
o IPv6 has the IPsec technology directly embedded into the IPv6
protocol.
See note above. IPsec is no more "embedded" in IPv6 than it is in IPv4.
This allows for simpler peer-to-peer encryption and
authentication, once a simple key/trust management model is
developed, while the usage of some other less secure
mechanisms is
avoided (i.e. md5 password hash for neighbor authentication).
o On a local network, any user will have more security awareness.
IPv6 will make users more security-aware? What does that even mean?
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) as there is no
Address Translater and hance no false safety perception.
o All flows on the Internet will be better traceable due to a
unique
and globally routable source and destination IPv6 address. This
may facilitate an easier methodology for back-tracing DoS attacks
and avoid illegal access to network resources by simpler traffic
filtering.
We already can trace these flows inside the NAT just fine. The only
place
it is now easier to trace is outside my NAT, where the attackers live.
o The usage of private address-space in IPv6 is now provided by
Unique Local Addresses, which will avoid conflict situations when
merging networks and securing the internal communication on a
local network infrastructure due to simpler traffic filtering
policy.
How is this a security benefit?
o The technology to enable source-routing on a network
infrastructure has been enhanced to allow this feature to
function, without impacting the processing power of intermediate
network devices. The only devices impacted with the source-
routing will be the source and destination node and the
intermediate source-routed nodes. This impact behavior is
different if IPv4 is used, because then all intermediate devices
would have had to look into the source-route header.
Again, how is this a security benefit?
A.5. Mobility
Anytime, anywhere, universal access requires MIPv6 services in
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
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.
Nice plug for MIP6, but why is it here? And, have you run this text
by the
MIP4 WG to make sure that they agree with it?
A.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. It will also allow to build virtual
organization networks on the fly, which is very difficult to do in
IPv4+NAT scenarios.
Uh... What is this all about? VPNs? Something else? Why is this
different in IPv6 than in IPv4?