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

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

James,

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.

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. 

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. 

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.

Tony


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of james woodyatt
> Sent: Thursday, April 19, 2007 1:35 PM
> To: IETF V6OPS WG
> Subject: Re: The argument for writing a general purpose NAT for IPv6
> 
> On Apr 19, 2007, at 12:47, Iljitsch van Beijnum wrote:
> > On 19-apr-2007, at 19:44, james woodyatt wrote:
> >>
> >> An RTSP server may *also* put any pair of UDP port numbers
> >> (starting on an even number) in the client_port attribute of a
> >> Transport header, so the ports that would have to be opened to the
> >> whole Internet include a very wide range, potentially *all* of them.
> >
> > That seems strange. Wouldn't the client want to have some say in
> > the port number it needs to open up?
> 
> I wasn't involved in the design of the RTSP protocol.
> 
> > But if we can define a range of port numbers that will pass through
> > firewalls, then obviously we can tell RTSP servers to use just
> > these ports.
> 
> There is no mechanism for RTSP servers to learn what ports they
> should be constrained to use.  Perhaps you mean we can tell RTSP
> server *administrators* to use just the ports we think are
> appropriate.  Alas, there is no mechanism for doing that, either.
> 
> >> You're telling me that the way to solve the problem is allow all
> >> UDP packets through the filter.  And that's just to make
> >> RealPlayer and Quicktime work properly.
> >
> > That's one option. But if the RTSP protocol is so unusual in this
> > respect that it can't live in an uPnP/NAT-PMP world, another option
> > would be to change the protocol. Some mechanism to allow for the
> > proxying that you need but without the address fakery makes sense,
> > but that may be hard to accomplish.
> 
> I have neither the option of changing the RTSP protocol nor the means
> to force RTSP server administrators to use a limited range of client
> ports.  I have to make Quicktime and RealPlayer streaming, as they
> exist today, work properly and sooner rather than later.
> 
> >> What about IPsec (without the ESP encapsulated in UDP) using ISAKMP?
> >
> > What do you mean by that? Packets with ip6->nextheader == ESP?
> 
> Yes.
> 
> > These are extremely simple firewall-wise: it's yes or it's no to
> > all of them. Obviously a firewall device can't be an ISAKMP proxy,
> > unknown entities in the middle messing with your packets is exactly
> > what IPsec is supposed to protect you against.
> 
> I think you might have missed an important part of the discussion.
> The problem is that outbound IKE initiations only punch holes for the
> well-known ISAKMP port.  They do not also punch holes for the
> associated inbound ESP packets without the assistance of an ISAKMP-
> aware gateway, i.e. basically an ALG for ISAKMP and IPsec flows.
> 
> > ESP packets that don't match any state at the host will be rejected
> > promptly without any adverse effects, so I don't see any reason to
> > invest a lot of effort to make sure only ESP packets that match
> > known state through the firewall device.
> 
> Without an ISAKMP ALG in the gateway, ESP packets that *DO* match
> state at the endpoint node will be rejected by the firewall.
> 
> >> I'd like to direct members of the group interested in continuing
> >> this discussion about IPv6 filtering behaviors to the ongoing
> >> discussion in the BEHAVE working group.
> >
> > In my experience, mailing list hopping halfway through a discussion
> > doesn't work too well. It would be good if the v6ops people could
> > reach some conclusion (and hopefully, consensus) on these issues.
> 
> I'm happy to continue the discussion separately or cross-posted to
> both working groups, as necessary.
> 
> If BEHAVE and V6OPS think relaxing the constraints on what inbound
> packets should be rejected by stateful packet filters in residential
> IPv6 gateway devices, then I'll take those recommendations to Apple's
> security team and see if they feel comfortable relaxing the behavior
> of future AirPort base station products.  At the moment, however, the
> recommendation is clear: no inbound packets should be passed unless
> they are associated with state matching flows initiated by local nodes.
> 
> I will agree: the more we can relax the constraints in question, the
> less need there will be to implement ALG's for IPv6 firewalls, and
> *therefore* the less demand there may be for the development of IPv6
> general purpose NAT, which is the topic of this particular thread of
> discussion.  That would certainly help.
> 
> I'm very pessimistic, however, that we can eliminate *all* of the
> impetus to implement ALG's for IPv6 firewalls without removing the
> constraint on inbound flows entirely, or by the implementation of an
> application listener discovery protocol for firewalls.  I'm more
> optimistic about the potential of the latter alternative than I am
> about the former.  To that end, I am drafting a proposal for solving
> this problem with a new ICMP sub-protocol.
> 
> 
> --
> j h woodyatt <jhw@apple.com>
>