[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The argument for writing a general purpose NAT for IPv6
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.)
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
--
j h woodyatt <jhw@apple.com>