Subject: Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)

From: Pekka Savola <[email-masked]>
Date: Mon, 15 May 2006 13:44:01 +0300 (EEST)

Hi,

I had a flight so I read this.  I think the document gives two very 
bad pieces of advice: turn off all NAT ALGs and remove all NAT state 
mapping filtering unless you require otherwise for security reasons.

Hence, I think wider IETF review seems warranted, and I'd encourage 
more folks to read the documents and raise their concerns or lack 
thereof.

More below.

On Tue, 9 May 2006, The IESG wrote:
> The IESG has received a request from the Behavior Engineering for Hindrance
> Avoidance WG to consider the following document:
>
> - 'NAT Behavioral Requirements for Unicast UDP '
>   <draft-ietf-behave-nat-udp-06.txt> as a BCP
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-05-23.

The document was very well written so it was easy to read.

As a generic comment, I'd like to know whether the different NAT mapping
methods have different scaling characteristics in terms of amount of state
created and in terms of external NAT ports/addresses reserved (compare to
the IETF list discussion a while back).

As another generic comment, I'd have liked this document to refer to RFC
4380 (Teredo), because IMHO that's probably the most useful generic
NAT traversal mechanism out there.

A few specific comments below,

substantial
-----------

    REQ-8: If application transparency is most important, it is
       RECOMMENDED that a NAT have an "Endpoint independent filtering"
       behavior.  If a more stringent filtering behavior is most
       important, it is RECOMMENDED that a NAT have an "Address dependent
       filtering" behavior.
       a) The filtering behavior MAY be an option configurable by the
          administrator of the NAT.

==> I think this is WAY too dangerous approach.  I'd say that the filtering
behaviour MUST be at least address dependent, unless explicitly configured
otherwise.

    NAT ALGs may interfere with UNSAF methods or protocols that try to be
    NAT-aware and must therefore be used with extreme caution.

    REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
       that all of those ALGs be disabled by default.
       a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
          the NAT administrator to enable or disable each ALG separately.

==> this seems like a VERY bad advice.  You're assuming that all the protocols
used within a site (which DO work with NAT ALGs) would use UNSAF mechanisms,
i.e., it's OK for them to fail with native NAT ALGs because they can just
fall back to using UNSAF methods.

I think that UNSAF mechanisms must be able to work with ALGs enabled by
default.  If they don't, they're too brittle and should be written in a more
generic manner, with non-ALG mechanisms.

semi-editorial
--------------

       Address Dependent Mapping:
          The NAT reuses the port mapping for subsequent packets sent
          from the same internal IP address and port (X:x) to the same
          external IP address, regardless of the external port.
          Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals
          Y1.

==> this would have been easier to understand if you had added 'only' before
'reuses'.  The same for Addr/Port Dep Mapping and respective filtering
sections.

    REQ-13: If the packet received on an internal IP address has DF=1,
       the NAT SHOULD send back an ICMP message "fragmentation needed and
       DF set" message to the host as described in RFC 792 [2].
       a) If the packet has DF=0, the NAT SHOULD fragment the packet and
          send the fragments, in order.

    Justification: This is as per RFC 792.
       a) This is the same function a router performs in a similar
          situation RFC 1812 [5].

==> RFC 1812 requires that a router MUST support fragmentation, though
proper ordering of fragments is a SHOULD.  So, I'm a bit puzzled by both
of these SHOULDs.  What is the alternative?  Silently discard packets with
DF set?  Silently discard packets with DF=0 which require fragmentation? 
Maybe these should be stronger..

    Arch-3: This does not reduce the overall brittleness of NATs but will
            hopefully reduce some of the more outrageous NAT behaviors
            and make it easer to discuss and predict NAT behavior in
            given situations.

==> not sure if I agree with this statement, because you're recommending
turning off ALGs which means that some applications are going to stop
functioning.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 May 2006 10:12:00 -0400

> behaviour MUST be at least address dependent, unless explicitly configured

I'd strongly disagree with that.  I'd say that NATs MUST NOT have 
address dependent filtering unless configured otherwise; and even then, 
filtering SHOULD be configurable on a (destination) port-by-port basis. 
  In other words, transparency MUST be the default setting.

> ==> this seems like a VERY bad advice.

I agree with this.  The problem, I suspect, is that this invites 
questions about which ALGs to enable and how those ALGs should behave, 
which is a big can of worms.  Some kinds of ALGs are very bad, others 
are essential and semi-harmless.  But it certainly should not be 
expected that apps will use UNSAF methods, as UNSAF methods are woefully 
inadequate.

While I appreciate the desire to limit the problem, I think this 
document is too narrowly scoped - there's no way to define a desirable 
NAT behavior that doesn't, at a minimum, allow explicit host/application 
control over bindings in the NAT.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 May 2006 12:23:44 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    >> important, it is RECOMMENDED that a NAT have an "Address
    >> dependent filtering" behavior.  a) The filtering behavior MAY
    >> be an option configurable by the administrator of the NAT.  ==>
    >> I think this is WAY too dangerous approach.  I'd say that the
    >> filtering behaviour MUST be at least address dependent, unless
    >> explicitly configured otherwise.

    Keith> I'd strongly disagree with that.  I'd say that NATs MUST
    Keith> NOT have address dependent filtering unless configured
    Keith> otherwise; and even then, filtering SHOULD be configurable
    Keith> on a (destination) port-by-port basis. In other words,
    Keith> transparency MUST be the default setting.

I have not yet read the document, but believe I understand the context
for this discussion point well enough to contribute.

I think that it is important to separate NAT from firewall
functionality.  One device may provide both functions.  But if the
intent is to provide only a NAT function,, then Keith is right and
transparency needs to be the default.

If the intent is to provide a firewall function then all the
manageability and configuration concerns of a firewall apply.

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 May 2006 13:31:44 -0400

> manageability and configuration concerns of a firewall apply.

this ends up trying to specify how a zero-configuration firewall should 
work, or how a firewall for a dumb customer should work out-of-the-box.

it's an unreasonable problem because the network is explicitly designed 
to be general purpose and to support an infinite variety of 
applications, but the fundamental assumption behind such a firewall is 
that the firewall can be aware of what is going on in the network and 
know whether or not the network behavior it is seeing is reasonable. 
the answer to the question of whether the behavior is reasonable is 
going to vary widely from one application to another and from one 
installation to another.  there's no way that the firewall can tell by 
looking.  even expecting all conversations to be initiated from inside 
the firewall is dodgy - partially because there are legitimate apps that 
need to not work that way, partially because there are conversations 
that involve more than two hosts at a time, partially because there are 
occasions when remote hosts are forced to change IP addresses.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 May 2006 19:08:37 +0200

> manageability and configuration concerns of a firewall apply.

The intent was never to describe how to build a firewall or a NAT. It  
was to provide a "safe harbor" of assumptions that an application  
behind a NAT or firewall could assume "behave compliant" NATs or FWs  
would provide. The BEHAVE WG has tried to find a balance between what  
had a chance of deploying and what would be enough transparency to  
allow some applications to work. Clearly more transparency would  
allow more applications to  19:29:22 -0700
From: Cullen Jennings <[email-masked]>
Date: Thu, 18 May 2006 19:08:37 +0200
To: Sam Hartman <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked],
	[email-masked], Pekka Savola <[email-masked]>
Subject: Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP
	(draft-ietf-behave-nat-udp)

> manageability and configuration concerns of a firewall apply.

The intent was never to describe how to build a firewall or a NAT. It  
was to provide a "safe harbor" of assumptions that an application  
behind a NAT or firewall could assume "behave compliant" NATs or FWs  
would provide. The BEHAVE WG has tried to find a balance between what  
had a chance of deploying and what would be enough transparency to  
allow some applications to work. Clearly more transparency would  
allow more applications to work but not if it will never be deployed.  
This particular item was discussed for a long time in the WG. The  
bulk of the running code we have today does not provide "address  
independent" mappings because of the associated security properties.  
Manufactures are building boxes that are designed for to sit in  
houses in front of windows machines run by technically  
unsophisticated users. I don't know if these boxes are NATs,  
Firewalls, or something else but no manufacture in their right mind  
is going to ship these boxes with the default as address independent  
mappings.

If we change this to "address independent", close to 100% of NATs  
produced will be non behave compliant. At this point applications  
will have nothing they can rely on and we will be at the same point  
we are now and the BEHAVE WG will have been reduce to an irrelevant  
waste of time.

I 100% agree that if we were advising people how to build NATs, we  
would recommend "address independent", however this is not the  
situation.

Cullen (with my individual contributor hat on)

work but not if it will never be deployed.  
This particular item was discussed for a long time in the WG. The  
bulk of the running code we have today does not provide "address  
independent" mappings because of the associated security properties.  
Manufactures are building boxes that are designed for to sit in  
houses in front of windows machines run by technically  
unsophisticated users. I don't know if these boxes are NATs,  
Firewalls, or something else but no manufacture in their right mind  
is going to ship these boxes with the default as address independent  
mappings.

If we change this to "address independent", close to 100% of NATs  
produced will be non behave compliant. At this point applications  
will have nothing they can rely on and we will be at the same point  
we are now and the BEHAVE WG will have been reduce to an irrelevant  
waste of time.

I 100% agree that if we were advising people how to build NATs, we  
would recommend "address independent", however this is not the  
situation.

Cullen (with my individual contributor hat on)

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 May 2006 22:44:11 -0400

> produced will be non behave compliant. At this point applications will 
> have nothing they can rely on and we will be at the same point we are 
> now and the BEHAVE WG will have been reduce to an irrelevant waste of time.

what's the point of this exercise?  to encourage predictable behavior 
that applications cannot use?  to give NAT vendors a seal of approval?

maybe it's just not possible to specify a NAT such that it's useful to 
application writers and vendors will build it...at least, not without 
significant functionality beyond just address translation and packet 
filtering.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 15:20:05 -0700

On May 18, 2006, at 7:44 PM, Keith Moore wrote:

>> will have nothing they can rely on and we will be at the same  
>> point we are now and the BEHAVE WG will have been reduce to an  
>> irrelevant waste of time.
>
> what's the point of this exercise?

To try and minimize the damage NATs cause - clearly if NATs all acted  
like a peice of cat 5 cable, that would be optimial from some points  
of view but this is not likely to happen. So it was a balance to  
define something that was extremely useful for applications (more on  
that later) and yet close enough to what NATs do that some, and  
hopefully most, NAT vendors will do it.

> to encourage predictable behavior that applications cannot use?

The functionaly here defined here allow two hosts behind two differnt  
NATs to be able to set up a dirrect flow of packets between them.  
They need an external STUN server in the public space to help them  
with this but they don't need to realy all the packets through a  
server. The two hosts use some server that is not NATed to help set  
up the connection, but once the connection is up, there is real e2e  
flow of packets and the packets don't have to be relayed by some  
public server. Clearly this is not as nice for applications as no  
NAT, but short of no NAT, this is really useful and helps provide the  
scaleabilyt and reliabilyt that would be achievable in a system with  
no NATs. VoIP, IM, and online games can all take advantage of this -  
and using ICE they can do it in a way that provides a smoth  
transition to v6 or envirnoments with no NATs. I think the behavior  
defined here is useful for applications.

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 May 2006 18:41:56 -0400

> To try and minimize the damage NATs cause 

Well, as far as I can tell, you're not doing that to any significant
degree. 

> NATs to be able to set up a dirrect flow of packets between them. 

A solution that only works for pairs of hosts is of fairly limited
applicability. Most two-host applications already work through NAT.
The biggest set of apps affected by NAT are distributed applications.

Again, maybe it's not possible to define a spec that NAT vendors will
implement that gets rid of NAT brain damage to any useful degree.  If
this is the belief of the BEHAVE WG then  the correct output of the
BEHAVE group is to state that belief, rather than to define a spec that
provides the appearance of a solution while only providing a very
marginal increase in actual functionality. 

Personally I'm tired of attempts to avoid solving the NAT problem while
glossing over it.  I don't think IETF should be endorsing NAT fixes
that don't provide a path to a viable long-term solution.