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