Re: [BEHAVE] (no subject)

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

Hi Ivan,

On 6/18/13 4:33 PM, "ivan c" <[e-mail]> wrote:

>Hi Senthil,
>
>Thanks for your message. You might want to read
>http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00
>It features the list of updates to the existing RFC, adapted to new usage
>contexts such as CGNs, mobile networks, etc.

I have reviewed this draft and we had a bit of discussion around these
topics in the last IETF.
>
>
>On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)"
>
>>>
>>>Are you talking about UDP port preservation?
>> 
>> Both TCP & UDP. The latest implementation in some router families is not
>> to have port preservation
>> (for both TCP & UDP).
>> 
>
>The discussion here is not about UDP. UDP port preservation should
>generally not be implemented by NATs, as it could generate conflicts when
>2
>internal hosts using the same local port, each with a session to the same
>endpoint. This would break end-to-end connectivity in rare cases, as there
>is no fallback mechanism (as opposed to TCP).
>
>To be clear, the requirements are as follows:
>* NAT SHOULD NOT use UDP port preservation
>* NAT SHOULD use TCP port preservation
>
>Here are some NATs that have been tested and implement TCP port
>preservation:
>in the UK:
>BT (British Telecom) (house-made gateway) - number 1 provider
>Virgin (house-made gateway) - number 2 provider
>Sky (Sagemcom) - number 3 provider
>
>in France:
>Orange (Livebox) (house-made gateway) - number 1 provider
>Free (Freebox) (house-made gateway) - number 2 provider
>SFR/Neuf (Neufbox) (house-made gateway) - number 3 provider
>
>This covers the overwhelming majority of subscribers.

Ok thanks for the pointers. The NATs that I was talking about were
enterprise/SP NAT boxes,
not the home routers. Many of the CGN implementations don¹t do port
preservation. 


>
>We have the same results in Spain in Italy.
>
>Misc:
>Linksys E1200, latest generation.
>Netgear, various models
>
>
>It is difficult to find any NAT that does *not* implement TCP port
>preservation in these countries.
>If you think some gateway implementations have dropped TCP port
>preservation, you need to substantially support your claim by a reference.
>We are not aware of anything that would support it.
>
>
>> 
>> Most of the NATs that I know don¹t do port overloading any more.
>> RFC 5382 also says,
>> REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>>       overloading" for TCP.
>> 
>
>This is the purpose of the new draft
>http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 , to
>make the use case for port overloading, as it is needed in CGNs. It wasn't
>needed nearly as much in 2005 when RFC 5382 was first written.
>
>REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
>overloading" for TCP
>is too stringent, as proved in my earlier message and in the
>draft-ietf-behave-requirements-update-00, and not needed.

There are two distinct things here:
1. Port preservation is a must
2. Port preservation requires port overloading to work deterministically.

I don¹t have a lot of problem with an implementation choosing to do port
preservation if it can.
I do have issues with doing port overloading. Two reasons again.
1. Port overloading requires the destination information to be tracked by
NAT devices. That kills scalability.
2. Port overloading causes packets to be dropped if two connections going
to the same destination, causing indeterministic behavior.
   
Maybe as Rajiv suggested in another thread, maybe we need a CPE NAT
requirements document where the above requirement might be placed.
But I don¹t know what good it is, if there is another CGN on the headend
that would not honor the port preservation. As I said, in my earlier
Email, the CGNs can now have a pre-allocated set of ports (like 1k
ports/sub), where there is no way to do port preservation.

Senthil

>
>Port overloading is perfectly acceptable when the remote endpoints are
>distinct, as it preserves the uniqueness of the 5-tuple.
>
>As a result, REQ-7 must be corrected.
>
>
>
>-- 
>_Ivan Chollet_