Re: [BEHAVE] (no subject)

[ivan c <[e-mail]>]

On Thu, 27 Jun 2013 15:55:24 +0200, Simon Perreault
<[e-mail]> wrote:
> Le 2013-06-27 15:44, ivan c a écrit :
>>> 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".
>>>
>>> RFC 5382:
>>>
>>>      REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>>>         overloading" for TCP.
>>
>> Because some NATs would like to do port overloading, which is in
>> contradiction with these requirements.
> 
> "Would like to" is not a valid reason. We need technical arguments.

That's right, but I think it's the above requirements that needed a valid
technical argument in the first place.
The only argument that was given is that the set of requirements
guarantees a deterministic (consistent) behavior of the NAT from the
application point of view.
But NATs never behave in a deterministic way, they might drop packets, or
random NATs can sometimes appear to be deterministic. And it is not the
point.
What is required is that the *interfaces* of each *protocol* behaves in a
deterministic way (ie, a function must behave according to its
specification 100% of the time). Generally, a deterministic NAT allows you
to write simpler protocols.
In this post, I explain how the TCP Hole Punching protocol determinism is
not affected:
http://www.ietf.org/mail-archive/web/behave/current/msg10896.html


> 
>> See section 4. of
>> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 .
>> You're mentioned as an author on this draft by the way.
> 
> I'm not disagreeing with myself. I am only observing that this 
> discussion still has not yielded any good technical argument that we 
> could add to our draft.

see above, I feel it is a valid point.


> 
> I have suggested that one condition where port overloading could be used

> is when the NAT knows that it will not disrupt the application protocol.

> For example, the protocols running on TCP port 80 and UDP port 53 (HTTP 
> and DNS) are purely client-server and therefore would not be affected by

> port overloading. Allowing NATs to do port overloading for those ports 
> only would probably solve the scalability problem since they account for

> a large portion of the traffic.
> 
> Do we really need anything more complex?

Allowing port overloading on 80 is the same as allowing it on all ports
(applications are free to use any port for any protocol, Skype for instance
uses port 80 for p2p communications).
Your suggestion is good though, because I don't think any protocol is
affected by port overloading. If they were, they would be badly designed,
but still I have never heard of any such protocol.


> We know that port overloading is desirable for a number of reasons.
> 
> What we need to argue is why the undesirable effects of port overloading

> do not apply or can be ignored.

Definitely, this is the main point of our argument.
I think we have progressed in this argument and provided useful material.
In this post:
http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I
explain (among other things), why the TCP Hole Punching Protocol is not
affected by the rare cases of collision due to port overloading. The
application simply retries with a new TCP socket (on a new local endpoint).

Also, it is mentioned in many RFCs that p2p applications need to expect
NATs to have a variety of non-deterministic behaviors wrt port allocation,
and have fallback mechanisms in place to deal with all cases.



-- 
_Ivan Chollet_