On 19-apr-2007, at 19:44, james woodyatt wrote:
However, let me propose a different direction for solving this: rather than waiting until a port number is selected, put into a control stream, then intercept that control stream, recover the port number and open up the firewall, why not simply set aside a range of port numbers for these types of purposes and let those through the firewall?
With IPv4 this wouldn't work because there has to be a mapping between an private and a public address, but with IPv6 that's not necessary.
An RTSP server may put any IPv6 address in the source attribute of a Transport header, so these ports would have to be open at all times to the whole Internet.
Right. So the question is, what are we trying to accomplish? If the host and the firewall device are working together, it doesn't much matter which of the two rejects unwanted packets. Since the host _does_ know what the RTSP server is up to, it can easily reject unwanted packets.
In my opinion, what you need the firewall device for is to make sure that you can run services on the internal network without exposing those services to the rest of the world. So as long as the firewall device rejects all packets that are addressed to ports where services may run, that's accomplished.
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? 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.
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.
What about IPsec (without the ESP encapsulated in UDP) using ISAKMP?
What do you mean by that? Packets with ip6->nextheader == ESP? 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.
Should I just pass all ESP packets through too?
This is once again a question of whether the firewall and the host are working together, or working against each other. As a home user I would expect my firewall device to let everything that I initiate from the inside through by default, but in a corporate environment it may make sense to distrust hosts and be more restrictive.
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.
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.