Re: [BEHAVE] (no subject)

[Simon Perreault <[e-mail]>]

Le 2013-06-25 18:46, ivan c a écrit :
> We have, for all UDP communications and all outbound TCP sessions:
> - one socket is bound to one local endpoint on the host. Additionally, two
> sockets have to bind to two different local endpoints.

Not true. If you call connect() on a UDP socket, it behaves just like a 
TCP socket.

> - one internal endpoint (=local endpoint) is mapped to one external
> endpoint on the NAT
> As a result, if no overloading, the NAT has to allocate a new external
> endpoint for every outbound TCP session.
> This doesn't apply to UDP.

Not true because of the above.

>>> Back to NAT port overloading. A collision occurs when 2 sessions share
>>> the
>>> same 5-tuple.
>>
>> Stop right here. Some NATs don't track sessions. Those NATs don't care
>> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple.
>
>> So for those NATs there is no conflict. They will just translate the
>> packets according to the existing mapping.
>>
>> All the following doesn't make sense to me given this.
>>
>
> Sure, *stateless* NATs also can't do much endpoint dependent filtering and
> lots of other
> things. They certainly can't do port overloading and are out of scope of
> this discussion.

I'm not referring to stateless NATs. I'm referring to stateful NATs that 
only map internal 3-tuple to external 3-tuple and do not do anything 
with 5-tuples.

> Nevertheless, NATs that do look at the full 5-tuple are free to implement
> port overloading if they wish.

I still haven't seen any explanation why the following excerpts do not 
apply.

RFC 4787:

    REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
       overloading".

    Justification:  This requirement must be met in order to enable two
       applications on the internal side of the NAT both to use the same
       port to try to communicate with the same destination.  NATs that
       implement port preservation have to deal with conflicts on ports,
       and the multiple code paths this introduces often result in
       nondeterministic behavior.  However, it should be understood that
       when a port is randomly assigned, it may just randomly happen to
       be assigned the same port.  Applications must, therefore, be able
       to deal with both port preservation and no port preservation.

RFC 5382:

    REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
       overloading" for TCP.

    Justification:  This requirement allows two applications on the
       internal side of the NAT to consistently communicate with the same
       destination.

Simon