[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of draft-ietf-v6ops-nap-02.txt
On Fri, Jun 30, 2006 at 12:37:16PM -0700, Tony Hain wrote:
> Network Working Group G. Van de Velde
> Internet-Draft T. Hain
> Expires: January 1, 2007 R. Droms
> Cisco Systems
> B. Carpenter
> IBM Corporation
> E. Klein
> Tel Aviv University
> June 30, 2006
>
>
> IPv6 Network Architecture Protection
> <draft-ietf-v6ops-nap-03.txt>
Hi Tony,
Some comments on this nap-03 version follow.
Overall, it is a good and a very useful document.
The Informational nature of the document should be stressed (vs BCP).
I think my general comment would be that the proposed IPv6 tools all have
their own tradeoffs, just as deployment of IPv4 NAT is a tradeoff. These
tradeoffs should be explicitly mentioned; I am not sure they are right now.
For example, privacy addresses have management issues (recognising hosts
over time), as does using ULAs with globals ('bugs' in RFC3484). Both
need more operational experience and/or (minor) protocol fixes. The topology
hiding solution has the biggest tradeoff, and that's probably why Margaret
has a bigger issue with that.
In addition to the considering the tradeoffs, we need to have some
operational experience from use of these proposals (to migrate the text to
BCP one day), and hopefully that will come soon.
For many admins, the topology and privacy issues will not be important. So
maybe there are different 'levels' of NAP that could be used, varying from
global addressing + firewall at the bottom then adding ULAs, RFC3041 and
topology hiding as additional features.
As an aside, if you defined IPv4 NAP, that would represent globals and
firewalls; you could even do the host routing. The advantage IPv6 has,
once proven, is the multi-addressing with ULAs and privacy addresses.
Inline comments:
Indeed, product marketing departments have
effectively driven a perception that some connectivity and security
concerns can only be solved by using a NAT device, without any
mention of the negative impacts on applications.
=> Isn't the main benefit is ease of deployment, for the typical home user?
And wasn't the word 'marketing' being removed throughout the doc?
header modification feature of NAT in an IPv6 network. It should be
noted that this document is 'informational', as it discusses
approaches that will work to accomplish the goals. It is
specifically not a BCP that is recommending any one approach.
=> This is hidden too well (see main comments :)
trail which is a fundamental security tool. That said, the artifacts
of NAT devices do provide some value.
1. The need to establish state before anything gets through from
outside to inside solves one set of problems.
2. The need to stop receiving any packets when finished with a flow
solves a set of problems
3. the need to appear to be attached at the edge of the network
solves a set of problems
4. and the ability to have addresses that are not publicly routed
solves yet another set (mostly changes where the state is and
scale requirements for the first one).
=> Are points 1-3 discussed later in the context of NAP? If those points
add value for NAT, NAP should be stated to match them.
+------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & 4193 |
| Autonomy | see section 2.5 | see section 4.5 |
+------------------|-----------------------|-----------------------+
=> RFC 4193 isn't mentioned in section 4.5?
+------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 17*10^18 subnets |
| Pool | << 2^48 application | 3.4*10^38 addresses |
| Conservation | end points | full port list / addr |
| | topology restricted | unrestricted topology |
| | see section 2.6 | see section 4.6 |
+------------------|-----------------------|-----------------------+
=> Make the numbers explicit? Where do they come from?
+------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime |
| Multi-homing | at border | per prefix & Multiple|
| | | addresses per |
| | | interface |
| | see section 2.7 | see section 4.7 |
+------------------+-----------------------+-----------------------+
=> Anyone for 8+8? :)
Wide-scale deployments have shown that using NAT to act as a simple
gateway attaching a private IPv4 network to the Internet is simple
and practical for the non-technical end user. Frequently a simple
user interface, or even a default configuration is sufficient for
configuring both device and application access rights.
=> Therefore IPv6 gateways must be simple to deploy too. Maybe the document
needs a new section that is simply "Simple to Deploy"? Then you could
discuss how simple it is to manage a stateful firewall, or to negotiate
firewall traversal for apps (as opposed to NAT traversal).
2.2. Simple Security due to Stateful Filter Implementation
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 is actually an illusion.
=> Which applies to IPv6, or IPv4 with globals used. The question is
more whether the address and port manipulation provides security,
and you answer that question anyway.
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 two or
more devices need to host the same application or otherwise use the
same public port this complexity shifts from difficult to impossible.
=> Maybe some operators want NAT for 'walled gardens'. But that's a
'political' statement maybe best avoided?
Some network managers prefer to hide as much as possible of their
internal network topology from outsiders as a useful precaution to
mitigate scanning attacks. Mostly this is achieved by blocking
"traceroute" etc., though NAT entirely hides the internal subnet
topology. Scanning is a particular concern in IPv4 networks because
the subnet size is small enough that once the topology is known it is
easy to find all the hosts, then start scanning them for vulnerable
ports. Once a list of available devices has been mapped, a port-scan
on these IP addresses can be performed.
=> Are IPv4 networks really that sparsely populated for that to matter?
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 sufficiently large pool for a clean and
hierarchical addressing structure in the local network.
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.
=> Maybe spell out that internal comms can keep working while renumbering
or disconnected. But this section also true because typically a NAT
network has clients accessing external servers, and not vice-versa.
The number of and types of applications that can be deployed by these
ISPs and their customers is restricted by the ability to overload the
port range on the public side of the most public NAT in the path.
The limit of this approach is something substantially less than 2^48
possible active **application** endpoints (approximately [2^32 minus
2^29] * [2* 2^16 minus well known port space]), as distinct from
addressable devices each with their own application endpoint range.
=> Expand on the working? Not clear where the numbers come from, as per
the same comment earlier.
The reader must clearly distinguish between features of IPv6 that
were fully defined when this document was drafted and those that were
potential features that still required more work to define them. The
latter are summarized later in the 'Gap Analysis' section of this
document. However, we do not distinguish in this document between
fully defined features of IPv6 and those that were already widely
implemented at the time of writing.
=> It's not just about what's defined, but also what we have operational
experience of, and tradeoffs in using the tools. For example, using
Privacy Addresses is fine, but has a price (management complexity).
3.1. Privacy Addresses (RFC 3041)
As originally defined, IPv6 stateless address auto-configuration
(SLAAC) will typically embed the IEEE Link Identifier of the
interface as the IID part, though this practice facilitates tracking
and profiling of a device through the consistent IID. RFC 3041 [7]
describes an extension to SLAAC to enhance device privacy. Use of
=> Maybe 'add' not 'enhance'?
the privacy address extension causes nodes to generate global-scope
addresses from interface identifiers that change over time,
consistent with system administrator policy. Changing the interface
identifier (thus the global-scope addresses generated from it) over
time makes it more difficult for eavesdroppers and other information
collectors to identify when addresses used in different transactions
actually correspond to the same node. A relatively short valid
lifetime for the privacy address also has the side effect of reducing
the attack profile of a device, as it is not directly attackable once
it stops answering at the temporary use address.
=> Maybe note the Privacy Address is only used for initiating outbound
connections; a node receiving connections inbound is likely to have
a separate global address, which is probably DNS-advertised.
3.2. Unique Local Addresses
o In practice, applications may treat these addresses like global
scoped addresses but address selection algorithms may need to
=> Actually they *have* global scope? See 3.3 of the ULA RFC.
The main goal of untraceable IPv6 addresses is to create an
apparently amorphous network infrastructure as seen from external
networks to protect the local infrastructure from malicious outside
influences and from mapping of any correlation between the network
activities of multiple devices from external networks. When using
untraceable IPv6 addresses, it could be that two apparently
sequential addresses are allocated to devices on very different parts
of the local network instead of belonging to devices adjacent to each
other on the same subnet.
=> As per the Network Scanning draft, I'd avoid sequential addresses,
rather emphasising the obfuscation of topology at the subnet view as
the important thing?
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. For smaller deployments this correlation
could be done by generating IPv6 host route entries, or for larger
ones by utilizing an indirection device such as a Mobile IPv6 Home
Agent. Additional details are in section 4.7.
=> This mapping may have some of the state complexity of NAT?
=> It may be that this is only needed for a part of a site, not all of it?
So a 50,000 node site may only want to hide certain parts, and a few
hundred nodes?
4. Using IPv6 Technology to Provide the Market Perceived Benefits of
NAT
=> Delete 'Market'?
With external connectivity the simple gateway should 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 derived from this prefix delegation. It should be noted
that the address selection policy table in end-systems defined in RFC
3484 should be configured to prefer the ULA prefix range over the
DHCP-PD prefix range when the goal is to keep local communications
stable during periods of transient external connectivity.
=> So are you advocating ULAs and globals in parallel? There are again
costs here (tradeoffs), e.g. possibly running split-view DNS, and
the 3484 'bugs' described in v6ops this week. The gotchas cited in
the 'Deprecating Site Locals' text need to be carefully considered
still, even with ULAs.
3. The size of the address space of a typical subnet (64 bits of
IID) will make a complete subnet ping sweep virtually impossible
due to the potential number of combinations available. Reducing
=> Change 'virtually impossible' to 'computationally difficult'?
Assuming the network administrator is aware of [19] the increased
size of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices.
=> Ditto on 'impossible'.
IPv4 NAT was not developed as a security mechanism. Despite
marketing messages to the contrary it is not a security mechanism,
and hence it will offer some security holes while many people assume
their network is secure due to the usage of NAT. IPv6 security best
practices will avoid this kind of illusory security but can only
address the same threats if correctly configured firewalls and IDS
systems are used at the perimeter.
It must be noted that even a firewall doesn't fully secure
a network. 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.
=> So maybe separate the network security here from application security
more explicitly. Focus on the pros/cons of the bit manipulations?
reflective session state). There should also be an easy interface
which allows users to create inbound 'pinholes' for specific purposes
such as online-gaming. Another consideration would be the capability
for service provider mediated pinhole management where things like
voice call signaling could dynamically establish pinholes based on
predefined authentication rules.
=> Here you mean firewall traversal not NAT traversal? I think there is
a difference worth making. The problem is shifted, but there.
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.
=> Again, there's a tradeoff here that's not mentioned.
Due to the large IPv6 address space available there is plenty of
freedom to randomize subnet allocations. By doing this, it is
possible to reduce the correlation between a subnet and its location.
When doing both subnet and IID randomization [RFC 3041] a casual
snooper won't be able to deduce much about the networks topology.
=> A tradeoff here is lack of aggregation, with scalability implications
for routing tables, but also implications if you want to renumber or
restructure parts of your network.
o One approach uses explicit host routes in the IGP to remove the
external correlation between physical topology attachment point
and end-to-end IPv6 address. In the figure below the hosts would
be allocated prefixes from one or more logical subnets, and would
inject host routes to internally identify their real attachment
point. This solution does however show severe scalability issues
=> As Margaret says, I think the tradeoff here is significant.
o Another technical approach to fully hide the internal topology is
use of a tunneling mechanism. Mobile IPv6 without route
optimization is one approach for using an automated tunnel, as it
always starts in tunnel mode via the Home Agent (HA). In this
=> As it is here.
4.5. Independent Control of Addressing in a Private Network
IPv6 provides for autonomy in local use addresses through ULAs. At
=> Do we mention PI proposals here, or leave that out?
4.6. Global Address Pool Conservation
IPv6 provides sufficient space to completely avoid the need for
overlapping address space. Since allocations in IPv6 are based on
subnets rather than hosts a reasonable way to look at the pool is
that there are about 17*10^18 unique subnet values where sparse
allocation practice within those provides for new opportunities such
as SEND 3971 [12].
=> Maybe say 2^n, which is... i.e. show the working in getting to that number.
5.1. Medium/large private networks
The majority of private enterprise, academic, research, or government
networks fall into this category. Many of these networks have one or
more exit points to the Internet. Though these organizations have
sufficient resources to acquire addressing independence when using
IPv4 there are several reasons why they might choose to use NAT in
such a network. For the ISP there is no need to import the IPv4
address range from the remote end-customer, which facilitates IPv4
route 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. By using address translation in IPv4 one
avoids the expensive process of network renumbering. Finally, the
customer can provide privacy for its hosts and the topology of its
internal network if the internal addresses are mapped through NAT.
=> Do we need to try to suggest using all the bells and whistles here?
For most sites, maybe using IPv6 and stateful firewalling is enough;
maybe they don't care about privacy addresses or topology hiding?
5.2. Small Private Networks
For the DHCPv6-PD solution, a dynamic address allocation approach is
=> Do you mean dynamic or automatic?
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.
=> Maybe some customers will want a random prefix each time (for better
privacy than 3041)? I wouldn't personally, but some will I'm sure.
6.1. Simple Security
Dynamic pinhole management is an area for further study. Several
partial solutions exist including ICE, UPNP, as well as alternative
proposals for Service Provider based control. The 'simple' aspect of
the security provided by a stateful firewall will require some degree
of automation to mask the technical complexity from the consumer that
only wants a secure environment with working applications.
=> This is firewall traversal rather than NAT traversal?
8. Security Considerations
While issues which are potentially security related are discussed
throughout the document, the approaches herein do not introduce any
new security concerns. Product marketing departments have widely
=> 'Marketing' used again?
This document defines IPv6 approaches which collectively achieve the
goals of the network manager without the negative impact on
applications or security that are inherent in a NAT approach. To the
degree that these techniques improve a network manager's ability to
explicitly audit or control access, and thereby manage the overall
attack exposure of local resources, they act to improve local network
security. In particular the explicit nature of a content aware
firewall in NAP will be a vast security improvement over the NAT
artifact where lack of translation state has been widely sold as a
form of protection.
=> Well, a NAT firewall *could* also be 'content aware' (do you mean an
IDS function here?)
This document has described a number of techniques that may be
combined on an IPv6 site to protect the integrity of its network
architecture. These techniques, known collectively as Network
Architecture Protection, retain the concept of a well defined
boundary between "inside" and "outside" the private network, and
allow firewalling, topology hiding, and privacy. However, because
they preserve address transparency where it is needed, they achieve
these goals without the disadvantage of address translation. Thus,
Network Architecture Protection in IPv6 can provide the benefits of
IPv4 Network Address Translation without the corresponding
disadvantages.
=> But there are other disadvantages, or tradeoffs. Maybe this can be
made into another general table?
=> Appendix A maybe repeats information in the main document. Does this
matter?
--
Tim