Subject: [Ietf-behave] Comments to draft-audet-nat-behave-00.txt

From: Harald Welte <[email-masked]>
Date: Sun, 15 Aug 2004 08:43:40 -0700 (PDT)

Hi!

First of all, let me introduce myself as one of the authors and
maintainer of the Linux 2.4.x and 2.6.x packet filter and NAT subsystem,
called netfilter/iptables.

linux-based NAT's are found in commercial products for professional use
from various vendors, but have recently gained huge market share in the
consumer markent NAT devices.

I'm mentioning this, since this seems to be unknown to a lot of people,
including the 'Vendors' themselves (which often OEM the devices and have
no idea what software is running on them).  Vendors shipping
netfilter/iptables based consumer NAT devices include Linksys, Belkin,
Buffalo, U.S.Robotics, Asus, Siemens, Fujitsu-Siemsns, Sitecom,
Airnyx, Arlotto, CenturySystems, Fiberline, Medion, Ovislink, Allnet,
...

This should be considered if somebody makes a statement like '75% of
NAT vendors present in this room' ;)

I am very happy about an IETF working group on unifying NAT behaviour,
and I think some guidelines/recommendations for NAT vendors would really
be helpful to NAT implementors.

>    Some particularly nasty NATs use Port overloading, i.e.  they
>    always use port preservation even in the case of collision (i.e.,
>    X1:x to X':x, and X2:x to X':x).  These NATs rely on the source of
>    the response from the external endpoint (Y:y, Z:z) to forward a
>    packet to the proper internal endpoint (X1 or X2).  

netfilter/iptables would be such a 'nasty' implementation.  Please note
however, that it cleanly handles thee 'port overload' case.

Reasons for this 'nasty' implementations are:

- don't change port numbers unless absolutely neccessarry.
  This adds extra transparency.  We hate that we have to do NAT 
  in netfilter/iptables, but we try to be as invisible as possible,
  causing the least of interferernce to applications.  And yes, there
  are protocols/applications that validate source port numbers (some DNS
  implementations, for example).

- don't waste port number address space (NB=PAD allows way more
  simultaneous sessions via a single public IP address than NB=I
  or NB=AD implementations)

> Port overloading fails if the two internal endpoints are establishing
> sessions to the same external destination.  

Which is a situation that is handled cleanly.  A clash of port numbers
is detected, and the source port number altered (as little as possible,
and only in the same range (i.e. <1024 will always map to a different
port < 1024).

So, obviously, I have some resistance to 'REQ-2b'. 

I support the proposal to change 'REQ-4' to 
        "MUST be "Outbound" or "Bidirectional", whereas "Outbound"
        is RECOMMENDED.

Reg. REQ-4a:  If (like in our implementation) a binding always only has
a single session [an inevitable consequence of being 'fully symmetric'],
does it fulfill the requirement? 

>  Non-deterministic NATs and firewalls are risky from a security point
>  of view.  They are very difficult to test because they are, well,
>  non-deterministic.  

Well, they are non-deterministic only if you don't know the rules
determining the 'non-deterministic' behaviour.

I don't really understand how this is a security risk. If a NAT tries to
preserve ports as long as possible (as long as the tuple of
[srcip,srcport,dstip,dstport] is unique) and alter the port only if this
is neccessary, how does this impose a security risk?  It might make a
certain application fail to connect in such an event - but security?

> Testing by a person configuring one may result in the person thinking
> it is behaving as desired, yet under different conditions, which an
> attacker can create, it may behave differently.

I agree, if 'testing' means 'functional testing' and not 'security
testing'.  And even then onl only if it is proven that an attacker can
create such a condition resulting in 'non-deterministic' behaviour.

>  These requirements recommend that devices be deterministic.

This contradicts REQ-9 whihc states 'MUST be deterministic'

-- 
- Harald Welte <laforge@xxxxxxxxxxxx>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
Attachment:
signature.asc