[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 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>