RE: The argument for writing a general purpose NAT for IPv6

["Tony Hain" <alh-ietf@tndh.net>]

james woodyatt wrote:
> On Apr 20, 2007, at 19:05, Tony Hain wrote:
> >
> > I am trying to catch up here, and I don't think I understand the
> > entire
> > picture. On one hand it looks like you are trying to insert a
> > transparent
> > application proxy for the purpose of applying inbound policy
> > without user
> > intervention. On another it looks like the only thing that you are
> > trying to
> > proxy are the control protocols for a couple of specific use cases. In
> > either case, the problem statement looks more like a perceived need to
> > transparently redirect traffic off its normal routing path. For the
> > example
> > given of the AirPort, it would be on-path by nature of its
> > packaging so it
> > would have access to implement the policies before forwarding
> > without the
> > need for any nat function. If I misunderstood please correct me.
> 
> I think you understand correctly.  I have both of these concerns.
> 
> On the one hand, there are certain applications that work over IPv4/
> NAT today, which do not work over IPv6 in the default configuration
> of AirPort Extreme because the IPv6 SPI filter blocks inbound flows.
> These applications are handled properly in the IPv4/NAT case by
> application layer gateways (ALG).
> 
> On the other hand, I have the additional concern that we may never
> have a method of enabling the utility of new peer-to-peer application
> protocols (which nameless boffins are busy designing in their
> basement laboratories even as I write, and which scale better and
> work more efficiently if no relays need to be reachable in the middle
> of the network) *without* having to deploy ALG's everywhere in the
> Internet to support them.  (See below for more of my thoughts about
> that.)

First thing we need to do is agree on terminology, not that I know the
answer, but it appears that your definition of an ALG & mine are different. 

To start with I would differentiate a signaling proxy from an ALG, where the
former may be required for rendezvous but does nothing with the content
stream, and the latter intercepts the content stream and in the case of nat
modifies it to deal with embedded addresses.

I would also differentiate ALG's based on if their primary purpose is to
establish an authentication checkpoint, or simply to align the content
stream with the nat mangling.


> 
> If the future IPv6 Internet turns out to be one very much like the
> existing IPv4/NAT Internet, then I'm going to need to be able to
> deploy ALG's quickly and easily as new application protocols emerge.
> That gives me pause, because I already know how the need for ALG's
> gives rise to the need for NAT, and I'm really *NOT* excited about
> the idea of making a name for myself as the guy who brought NAT to IPv6.

We should also come to some agreement about cause & effect. I don't believe
that the existence of an ALG creates a need for nat, but the existence of it
does allow for the 'opportunity'. SOCKS proxies existed long before nat, and
fill one aspect of a perceived need for a managed boundary. 


> 
> > It would be useful to understand a deployment scenario where the
> > normal
> > state would be to intentionally divert traffic off the routing path
> > to a
> > middle box. In particular, it would need to be clear why that would
> > not be
> > done by encapsulating at the diversion point, or even simpler by
> > forcing the
> > device to be on-path by aggregating the policy impacted nodes
> > behind it on a
> > dedicated subnet.
> 
> This is, I want to be careful to admit up front, a bit speculative.
> I may be out of my depth, and I'm hoping to be corrected if my
> understanding is wrong.  Here's one possible scenario that seems like
> the general case that has me concerned:
> 
> Consider the case of an application layer gateway for RTSP deployed
> in the firewall for a large population of endpoint nodes, i.e.
> numbering in the hundreds of thousands or even millions.  Grant that
> much of the RTP/RTCP traffic will be sent from media servers to
> clients on different paths than the reverse path from the RTSP
> servers.  Also grant that the fraction of endpoints using RTSP at any
> given time is small enough that the network can be provisioned with
> vastly fewer RTSP proxy nodes than stateful packet inspection
> firewall/routers.

I am willing to be open minded here, but that last point is hard to follow.
Very few organizations want an abundance of firewalls, so a vastly reduced
number of RTSP proxies sounds like a stretch. Typically the goal is to have
as few places where policy needs to be enforced as possible, just to make
sure it is being enforced consistently. 

> 
> In this scenario, diverting the RTSP stream from the firewall/router
> to the RTSP proxy transparently should probably be done by
> encapsulation rather than NAT, but let's be honest about how this
> will probably be developed in practice.  Once you've already got an
> RTSP proxy that works using NAT to redirect into a node-local
> interface address (just like your existing RTSP proxy already does
> with IPv4), the shortest path to getting your larger scale RTSP proxy
> system up and running is to reuse the mechanism you already have
> going.  Rather than encapsulate (which comes at the price of having
> to write the code that decapsulates at the other end of the tunnel
> and still lets TCP process the packets and present an octet stream to
> the proxy function), you just redirect with the NAT to an RTSP proxy
> node at a different address.  This is much easier.  That's how
> developers will do it.  I know that's how *I'M* currently planning to
> do it.

This description screams out for use of the routing extension header. Off
the top of my head it is not clear to me that the firewall could insert one
without breaking something else, but if you don't want to write
decapsulation code at the receiver, the routing extension header would allow
diverting traffic to it while maintaining the original destination. Since
this is assumed to be 'transparent' the origin of the packet would not know
the diversion destination, but if it were defined that RTSP always carried
at least an empty routing header, then the firewall could move the original
destination there and forward to the proxy. The extension header parser in
the proxy would already know how to swap those back before forwarding on. 

> 
> The idea of forcing the client devices to be on-path by aggregating
> the policy impacted nodes behind it on a dedicated subnet seems
> interesting.  What mechanism would you envision for doing that in the
> scenario outlined above?

I was not thinking about simple restriction to a subnet, rather that the
policy enforcement points would be limited in number and a collection of
subnets would naturally be aggregated behind those for routing. 

> 
> I should also mention that my additional concern about applications
> that haven't yet been developed is part of what has me champing for
> an alternative to deploying ALG's everywhere.  It would be nice to
> have a long-term solution that didn't require constant upgrades to
> the middleware.

That was the point of IPv6. 

> 
> Self-organizing peer-to-peer applications seem to be generally
> incompatible with stateful packet filters that block all inbound
> flows by default.  I understand that many in the Internet engineering
> community don't consider this failure of end-to-end connectivity to
> be a great loss, but I think ordinary users will be unhappy with the
> final consequences in terms of application usability unless some
> ALG's are deployed to relax policy enforcement according to the
> specific needs of applications that can benefit from them.

Again, we need to agree on terms here. A signaling proxy would be needed,
and a mechanism to dynamically manage the firewall would have to go with
that, but an ALG for the content stream doesn't sound like it is required.

> 
> Solutions like STUN/ICE/whathaveyou will always depend on the
> existence of two things that do not now exist: 1) a global peer-
> rendezvous service, and 2) a well-defined standard behavior for
> unmanaged IPv6 SPI firewalls.  I can see problems ahead trying to
> bring up solutions for each of those problems.  I don't see how we
> can escape the need for ALG's, and probably NAT as well, by relying
> only on SPI side effects.

I agree that the IETF has not figured it out yet, but look at NTT's m2m-x
effort:
http://www.v6.ntt.net/02e_02m2mx.html
They have been thinking about this problem space for awhile now, and while
the signaling protocol can be debated, the need for coordination between the
signaling system and the firewalls is clear.

> 
> I do think there are ways to avoid the need for ALG's, but they're
> going to require a lot of socialization-- and that's why you see me
> here trying to raise the visibility of these issues, partly by
> highlighting the costs of not doing anything, and also by pointing
> out practical avenues of development that could lead to practical
> solutions.

The -nap doc was a start at the problem space. If we need to do additional
work to make your RTSP indirection work, then we should start another doc
that clearly states the problem and the trade-offs like
encapsulation/routing-extension/...

> 
> > While I would encourage a draft on an ICMP protocol type for pinhole
> > management to raise the issues, I think one the reasons that the
> > IETF has
> > trouble in the policy management space is the carve-off-a-tiny-piece
> > approach to everything, particularly without any intent to
> > understand the
> > entire environment. Boiling the ocean is not productive, but
> > defining a
> > systemic framework where the carved up pieces have some hope of
> > relating to
> > each other (in some environments that might be called an
> > architecture) is
> > what the IETF lacks. We have a pile of piece-parts that have been
> > defined to
> > solve someone's hot-button, but nothing works together in a way
> > that allows
> > a consistent policy to be implemented across a range of functional
> > need.
> 
> Perhaps, now would be a good time to reiterate that Apple designed
> the NAT-PMP protocol intending for it not to be easily extended into
> more than a transition mechanism for IPv4/NAT, only to be used until
> IPv6 deployment is ubiquitous.  It was a carve-off-a-tiny-piece
> approach because that was good architecture.

I was thinking more along the line that we have RSVP, COPS, NSIS, SIP, pick
your favorite signaling protocol related to policy, but none of them do more
than a small part of what a policy system needs.

> 
> Everyone with whom I've talked about this at Apple believes that any
> proposal for a permanent addition to IPv6 for firewalls to discover
> application listeners will require an extremely thorough
> architectural review.  Ideally, we'd like to see the members of IAB
> join this discussion and offer whatever advice they think would help
> the working group build consensus around an architecturally sound
> solution to the class of problems under discussion here.

Again, take a look at m2m-x. My comment to them was to use IPsec for auth
between the client and the firewall for pinhole management, and to
specifically insert a local SIP proxy for cases where the enterprise does
not want to allow the carrier to manage the firewall pinholes directly.

> 
> > It sounds like you might have a use case that the -nap- draft does
> > not deal
> > with. I was presented with another a couple of weeks ago. I do not
> > want to
> > derail the effort to get the current doc out, because it needed to
> > be in RFC
> > form about a year ago, but we should start on an update to it that
> > covers
> > issues the current doc misses and how to resolve them without
> > resorting to
> > nat.
> 
> In the case of draft-ietf-v6ops-nap, the thing I was initially trying
> to help avoid has now already happened in my immediate circles, i.e.
> product management has interpreted an INFO as a BCP.  It turned out,
> much to my embarrassment, that this really wasn't much of a mistake,
> and that nobody really cares about the distinction between a
> recommendation in an INFO and the same recommendation in a BCP.

Lacking operational practice to clearly establish 'best', any information
will automatically fill the void.

> 
> I do still think there is a huge, glaring, problem before the V6OPS
> group, involving 1) unmanaged IPv6 networks subject to policy
> enforcement by 2) unmanaged stateful packet filtering firewalls.
> Whether that's really an open problem in the NAP draft, I'll leave to
> others to decide.

You will have a very hard time with 'unmanaged' in most of the IETF, because
they are all technologists that understand how to manage, and most of them
build products for professional managers so they just can't get their minds
wrapped around the complexity that goes into masking the guts from the end
user. Never mind the logical disconnect between 'policy enforcement' as a
management function and the need to do that in an 'unmanaged' way.

Yes we need a policy signaling protocol suite that can deal with the real
trust boundaries in deployed networks, and that does not create a
significant burden on application deployment. ALG's (as in mangles the
content stream) are not the answer, because as you note they require
coordinated updates to deploy the yet to be dreamt up application. 

Tony