Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Jun 2005 06:25:19 -0700 (PDT)

I agree with Saikat reasoning and would be fine with his proposed text of.

> REQ-7:
>         It is RECOMMENDED that a NAT have an "Endpoint Address dependent
> filtering" behavior.

I think some other people might have objected to the "Endpoint" filtering at
some point but I did not. I could also be convinced to go with something
along the lines of Bryan's proposal of

> REQ-7: In order to maximize application transparency, it is RECOMMENDED that
> a NAT have an "Endpoint independent filtering" behavior. If a more stringent
> filtering behavior is required, it is RECOMMENDED that a NAT have an
> "Address dependent" behavior.

We would need to restructure this slightly because I don't think we can
simultaneously RECOMMEND two contradictory things but I would be ok with
keeping he meaning the same. On the subpoint of

> a) The filtering behavior SHOULD be a user configurable option.

I could deal with this if we change to MAY but strongly object to the
SHOULD. There are going to be devices where this is difficult. There are
going to be devices that only support one type. In many case the
administrator of the NAT is very different from the user of it. There is no
reason why the WG should tell vendors how to build this. Having it as MAY or
SHOULD does not change any interoperability issues between devices. Any
standards body should focus on things that it needs to specify to ensure
interoperability. Once vendors start down the slipper slope of not being
fully compliant, pain and suffering will ensue - I'd rather avoid that. It's
about as useful for the draft to say that all NAT user manuals SHOULD be in
gender neutral language. It has no effect on interoperability. I can not see
any good come it and I can see harm caused by it when key vendors that are
not fully complaint start justifying why it is not useful to be fully
complaint with BEHAVE. I know it sounds weird to care about this, but I
would like to have a chance of getting the largest vendor of residential and
corporate NATs to do this and this is not going to help.

I also be fine with other proposals like

>>         NATs SHOULD support Endpoint Independent Filtering or Address
>>         Dependent Filtering, and  MAY support Address and Port Dependent
>>         Filtering, as options configurable by the administrator.
>> 

and I'd be fine with

> REQ-7: 
>    A NAT SHOULD support Endpoint Independent Filtering
>    or Address Dependent Filtering.

Cullen <not as chair>

On 5/29/05 12:28 AM, "Saikat Guha" <saikat@xxxxxxxxxxxxxx> wrote:

> On Fri, 2005-05-27 at 11:36 -0700, Cullen Jennings wrote:
>> On 5/27/05 3:29 AM, "Bryan Ford" <baford@xxxxxxx> wrote:
>>> On Thursday 26 May 2005 13:25, Francois Audet wrote:
>>>>         A NAT should support Endpoint Independent Filtering
>>>>         or Address and Port Dependent Filtering.
>>> 
>>> it may be highly beneficial to the
>>> long-term health of the Internet:
>>> 
>>> (a) to ask NAT vendors to allow users to disable connectivity-limiting
>>> firewall functionality
>>> 
>> Most NATs are also a firewall, this group is not doing firewall stuff but
>> saying that the default configuration has to be incompatible with normal
>> firewall functionality is just not realistic
> 
> I agree. My view is that, in the long term:
> 1) consistency among vendors is important
>    (thats what the NAT problem is about in the first place)
> 2) security is important
>    (opportunistic firewalling is unavoidable)
> 
> Taking a step back, the whole idea of EF=I is it is supposedly more
> 'application-friendly' and EF=A and EF=ADP are less so. I disagree. I
> believe both are equally app friendly (or unfriendly). Consider what
> needs to be done to setup UDP (assuming NAT is NB=I which is
> uncontested):
>              +---+
>              | S |
>              +---+
> +---+  +---+   |   +---+  +---+
> | A |--| N |---+---| M |--| B |
> +---+  +---+       +---+  +---+
> 
> A wants to set up UDP with B. N and M are NATs. S is a STUN-like server.
> 
> EF=I
> ----
> 1. A sends packet to S to learn binding
> 2. B sends packet to S (so it can learn A's address)
> 3. S sends A's binding to B
> 4. B sends packet to A's binding
> 5. A sends packet to B's binding (src of pkt #4)
> 
> Here packets 1-3 are unavoidable. A needs to reserve a binding and B
> needs to learn of it. Now consider the case with EF=A
> 
> EF=A
> ----
> 1. A sends packet to S to learn binding
> 2. B sends packet to S (so it can learn A's address)
> 3. S sends A's binding to B
> 4. S sends B's binding to A
> 5. B sends packet to A's binding (dropped)
> 6. A sends packet to B's binding
> 7. B sends packet to A's binding
> 
> The only change is that A explicitly learns B's binding from S and not
> from the packet B sent. You may say #7 is an extra packet ... but think
> of it as a retry that would have to be implemented for the previous case
> in the event that pkt #4 is dropped due to congestion. The only
> difference is handling that one extra packet from S to A. FWIW, it even
> _simplifies_ the application's state machine since the connection setup
> becomes identical on either side ... and agnostic to the EF type of the
> NATs. 
> 
> The first reaction is that if it were EF=I, then a new NAT'ed host C
> wouldn't go through this long process. Not true. If you repeat the
> analysis above, you'll find that, as before, only one extra packet (from
> S to A) is needed. Furthermore, the "complexity" of the application is
> the maximum complexity at A, B, C and not the complexity of one branch
> of some if-statement.
> 
> In the long term, what does EF=I taken in conjunction with the other
> recommendations buy us over EF=A?
> - Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works.
> - Simpler application? NO! See above.
> - A warm mushy feeling that we didn't tackle security in the NAT
> document? Yes.
> 
> In contrast, EF=A enhances security (think buffer overflows) and the
> icky feeling that the NAT document proposed *what the NAT vendors will
> end up doing anyway*. I'd say it makes the apps simpler even.
> 
> If I were to be so bold as to invite a flame war, I would make the
> following suggestion:
> ++++++++++++++++++
> REQ-7:
>         It is RECOMMENDED that a NAT have an "Endpoint Address dependent
> filtering" behavior.
> ++++++++++++++++++
> 
> Before you hit reply ... consider what happens in the long run.
> 
> 1) NAT behavior becomes more consistent
> 2) Connection setup becomes NAT-agnostic -- simplifies application
>    (the complexity in apps is not the extra packet/logic but rather
>     deciding what to do dynamically based on the type of NAT)
> 3) Given the two evils, we recommend the one that enhances security
>    rather than pretend that security has no place in the NAT rfc.
> 
> (Note EF=I is still RFC compliant ... just not recommended)

---

From: Bryan Ford <[email-masked]>
Date: Wed, 1 Jun 2005 09:32:00 -0700 (PDT)

On Wednesday 01 June 2005 09:25, Cullen Jennings wrote:
> administrator of the NAT is very different from the user of it.

Excellent point - in fact, your comment made me realize that the wording of 
the proposed recommendation above (suggested by Francois) does not quite 
match what I had in mind - what I actually want is more along the lines of:

 a) The filtering behavior SHOULD be an option configurable by the
    administrator of the NAT.

I completely agree that we can't expect the NAT's behavior to be configurable 
by the "end-user" (the bloke making connections through the NAT), when the 
end-user isn't the one who actually controls the NAT.  My intention (from the 
start) was only that this aspect of the NAT behavior should be configurable 
by whomever actually _does_ deploy and control the NAT.  In the case of 
ISP-deployed or corporate NATs, it should be configurable by the ISP's or 
company's network administrator, not necessarily by individual users of the 
company's network.  Similarly, in the case of low-end "locked" residential 
NATs that the ISP provides and controls exclusively, the ISP is effectively 
making itself the "administrator" of the NAT, and taking this power away from 
the end user.  Neither of these situations create any problems for the NAT 
being made configurable by the NAT's _administrator_ (e.g., the ISP), as per 
the revised wording above.

As Jon Peterson pointed out a while ago, the BEHAVE group's documents are 
intended to constrain NAT _vendors_, not the deployers or administrators of 
NATs, and what I care about with regards to this point is that the _vendor_ 
should not "hard-wire" a restrictive filtering policy into the NAT that 
cannot be disabled by whomever purchases and subsequently administers the 
NAT.  Whether the _end user_ actually gets to make that decision is a 
separate issue that depends on the relationship between the user and the 
NAT's administrator, and I don't propose to make any statement in that regard 
in a BEHAVE document.  I can see no practical reason why any new NAT should 
not have filtering behavior configurable by whomever actually holds the power 
and responsibility for configuring and administering the NAT.

I apologize if this minor confusion between "user" and "administrator" has 
been a major source of disagreement; I should have caught this wording 
subtlety earlier.

Cheers,
Bryan