[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Long term vs short term, was: Re: The argument for writing a general purpose NAT for IPv6

Hopefully a change of the subject line will draw in more people, I think this is an important issue.
The issue being: what is the right thing to do in the long term, and what is the right thing to do in the short term. In the short term, changing protocols like RTSP isn't an option, but in the long term, it's not even an issue. What we have to avoid is starting something because it makes short in the short term that will hurt us in the long term.
In order to determine what our options are, we need to define the problem. Off the top of my head I can think of five applications or classes of applications that don't work with a simple stateful firewall: 

1. Anything that listens for incoming sessions
2. Active FTP
3. SIP
4. RTSP
5. IPSEC

Possible solutions:

A. NAT-PMP like
B. ALG without host involvement
C. ALG with host participation
D. Open range of ports/protocols
I don't know very well how SIP or RTSP work, but I think the compatibility is as follows: 

A: helps with 1, 3, 5; doesn't help with 2, 4
B: helps with 2, 3, 4; doesn't help with 1, 5
C: helps with 2, 3, 4, 5; doesn't help with 1
D: helps with 3, 5; doesn't help with 1, 2, 4

This means we need at least A, and either C or both B and D.
Alternatively, we could collectively decide that this is too problematic and too harmful to the e2e principle, so we shouldn't have stateful firewalls in the common case after all. However, in that case we need to come up with a way to provide services on a local network in such a way that those services aren't exposed to the rest of the world. That would mean providing these services over non- routable address space, such as link-local for unmanaged installations and unique site local for larger installations. Apple would probably be in a good position to do this because Mac OS doesn't expose any services by default, but I think this is (still) different for Windows.
This would also mean that services aren't just enabled or disabled, but they are enabled for global use, enabled for local use or disabled. 

Back to our earlier exchange...

On 19-apr-2007, at 22:34, james woodyatt wrote:
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.
This is where the short/long term issue comes up: the IETF could easily update the RTSP specs to do this, but it would take years for that to take effect, so that's of no short term value.
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.
All of this comes with the territory, you simply can't have a middlebox meddle with IPsec. However, I don't see any security issues with allowing ALL protocol ESP packets through firewalls, because IPsec has a very good handle on which packets it wants to see and thus, which packets it doesn't want to see. No need to have a firewall "protect" hosts. Unfortunately, people have been living behind firewalls for so long that receiving packets from the big scary internet simply feels "wrong".
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. 

Ok. I'll subscribe to BEHAVE tomorrow.
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.
Maybe it would be useful to ask the chairs for a consensus call. However, this generally only happens when there is a draft.
In my opinion, a firewall shouldn't have to reject ALL packets for which there is no state, but for consumer stuff, the protection against possible malicious incoming traffic should be the same for IPv6 as it is for IPv4+NAT.
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.
Ok. It looks to me that you have a better view of the problem than (almost?) anyone else, so don't be afraid to take the position you think is right in both the long and short term, there is precedent for the IETF membership to be convinced by rational argument. :-) 

Iljitsch