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

The argument for writing a general purpose NAT for IPv6

On Apr 16, 2007, at 13:46, Mark Smith wrote:
On Mon, 16 Apr 2007 11:37:25 -0700, james woodyatt <jhw@apple.com> wrote: 

Yes.  I have to do this to make application layer gateways (ALG) for
IPv6 to be fully transparent.


They won't be "fully transparent". The devices on the public side of
the NAT will be able to detect them, or conversely, will break because
those devices or applications assume (quite reasonably, because that's
the (IPv6) Internet architecture) that there is a one-to-one mapping
between a network layer device and address.


p1. The mapping between nodes and addresses is already not one-to-one.
p2. I don't see the NAT required for IPv6 ALG's as breaking end-to- end addressability.
Whether network policy permits application reachability is independent of whether applications are addressable. I only think NAT needs to be used to redirect application flows between middleboxes, not between application endpoints in separate addressing realms. 


Having had to deal with the problems that "transparent" ALG devices
cause at the network layer, I don't want to see them again. e.g.
traceroute doesn't show the path the traffic is actually taking, they
create performance bottle necks, you have to traffic engineer certain
traffic to always pass a certain point in the network so that the ALG
gets a look at it, [...].
If stateful packet filters are widely deployed in residential IPv6 gateways and turned on in the factory default mode, I can only see one way to make some of those problems avoidable: by defining something as a bump-in-the-stack that uses a yet-to-be-defined ICMP subprotocol for signaling application listeners to the packet filters in the path, and rolling that out everywhere in the Internet instead.
Personally, I think this alternative makes better sense over the very long term, but my experience is that the very long term always comes at a lower priority than the end of the current financial quarter. 


[...] they create problems with remote websites and
applications that very reasonably assume a one-to-one mapping between
an IP address and a user.
Yeah, but there are security considerations there. RFC 3041 is an effort to address some of those, and not in a way that will make it *easier* for remote websites to continue assuming a one-to-one mapping between IP addresses and users. This was always a dumb assumption, and it will only get dumber with IPv6, no matter what we do to resolve the problems I'm trying to highlight here.
Can you describe some of those interactions ? As far as I'm aware RTSP, as do other applicaton protocols above the transport layer, just use IP 
as a dumb packet transport between specified IP addresses.
Sure. Both the RTSP client and server write IP address and UDP port numbers for the RTP and RTCP flows into the RTSP headers. The stateful packet filter that blocks incoming flows will need to inspect the SETUP method and search for the "Transport:" headers, parse them for the source, destination, client_port and server_port attributes, and open/close pinholes for them as needed.
There are other applications, I'm sure, that have similar problems. As noted, ISAKMP/IKE is one of them unless ESP encapsulation in UDP is used in conjunction with some kind of ICE-like UDP probing scheme to keep the outbound UDP pinhole open while incoming UDP/ESP- encapsulated flows might be received.
I'm pretty sure that BitTorrent is another such application. Also, I'm given to understand that some VoIP applications may be broken by the stateful packet filtering IETF recommends unless there is an ALG present for the application. 


I figure while I'm doing that, I might as well write a general
purpose IPv6 NAT.  I wish I didn't have to do this, but the security
considerations are pushing me into it.


Can you detail those security considerations ? I'd find it hard to
believe that NAT is the only security technique (and personally I don't 
really consider it to be one anyway) that solves your problem. What
unique property does NAT provide that no other alternative (such as
stateful firewalling with public addressing) doesn't?
I only *NEED* the NAT to redirect flows into transparent ALG's to support the stateful packet filter. (I'd say it's the market that seems unconvinced-- despite the laudable efforts of the authors of the NAP draft-- that IPv6 is sufficient for their needs without general purpose NAT being available, but that's not really my concern.) 

I'm considering the task of writing a general purpose IPv6 NAT because:

1) I now have to maintain a full suite of ALG's for both IPv4 and IPv6;
2) I've got a collection of IPv4 ALG's already that depend on NAT to work; 

3) I will still have support IPv4/NAT for the foreseeable future;
Therefore... the easiest way forward for me is the shortest path: by extending my general purpose IPv4 NAT to support IPv6. It saddens me to have to do it, but there it is. 


--
j h woodyatt <jhw@apple.com>