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

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

I have been arguing for a long time now that we should be following the 3484
approach of 'smallest scope' by default (and I use the term scope with
intent). For example, there is no reason a printer should bind to anything
but a ULA prefix by default. I have heard complaints that the API does not
allow a service to register for a specific prefix range like ULA, but I have
not followed up to check that. While I understand that the app developer
does not want to worry about issues like scope, in the real world the
network is managed with scopes where policy is applied. Frequently the
addressing allocation aligns with those policy scopes, and can be
specifically forced to align when traffic needs to traverse a policy
enforcement point. 

One of the 'attitude' problems we have is that the people that want absolute
control through centrally managed knobs absolutely insist on B and reject C,
while people that write apps want to get deployed without having to wait for
the knob to be flipped globally, so they lean toward C and want A & B
abolished. I disagree that C does not help with 1, unless the app in the
case of 1 assumes there is no external filter. If 1 assumes there is a
filter but does not know where, it would seem a reasonable thing to do would
be to send an ICMP toward default that would be dropped by the pinhole
device at the border (one could debate about dropping it at the first device
since a layer of filters would need to propagate all the way up, but sending
it outside the policy realm makes no sense either).

Tony


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Iljitsch van Beijnum
> Sent: Thursday, April 19, 2007 3:52 PM
> To: james woodyatt
> Cc: IETF V6OPS WG
> Subject: 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