Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis

[Kengo Naito <[e-mail]>]

Hi Ivan,

Thank you for the review of our draft.
Please see my comments inline,

(2013/06/17 4:14), ivan c wrote:
>
> Hello,
>
> This is my review of draft-penno-behave-rfc4787-5382-5508-bis 
> <http://www.ietf.org/mail-archive/web/behave/current/msg10831.html>, 
> which is indeed a step in the right direction and corrects omissions 
> and unspecified behaviors left by previous documents. I support its 
> adoption as a working group document.
>
>
> * 3.1.2.1. Rewrite timestamp and sequence number values at NAT
>
> Requiring NATs to rewrite timestamps and ISNs seems overkill. 
> Generally, mangling with the TCP protocol header other than by 
> rewriting the source endpoint should not be done by NATs.
> On the other hand, improving the current situation regarding the 
> TIME_WAIT state by carefully designed filtering rules without altering 
> the TCP header seems acceptable.
>
Then, how about using 3.1.2.2 ? This alternative do not rewrite 
timestamps nor ISNs.
Also, I do not intend to make 3.1.2.1 "must", this is only one of 
alternatives.

>
> * 4. Port overlapping behavior
>
> This is becoming a pressing issue due to increase deployment of CGNs 
> for IPv4 worldwide.
> As far as I know, the traditional term to describe this behavior is 
> "port overloading". The term overlapping refers to when two sets have 
> a non empty intersection (they are said to be "overlapping" sets). 
> Overloading is the correct term and was previously used in RFC5382 and 
> RFC4787.
> Port overloading is problematic for UDP, as P2P applications generally 
> multiplex several UDP communications over the same socket. The 
> probability that two internal peers communicate to the same remote 
> endpoint can be non-negligeable, depending on the number of UDP 
> communications and characteristics intrinsic to the p2p application. 
> See Birthday Paradox.
>
In the draft, I meant that Port overlapping behavior can only be used 
when the 5-tupple of connections are different.
So I think it is a bit different from overlapping behavior you wrote.
Does this behavior cause any bad effect?

> For TCP, this problem does not arise nrealy as much as there is a 
> one-to-one mapping between sockets and TCP communications (POSIX does 
> not allow to bind multiple sockets to the same local endpoint for 
> outbound connections). Thus the probability for conflict is much lower.
>
> [RFC5382] REQ-1 indeed requires EIM, but it is important to note that 
> the EIM behavior is required by applications that rely on a POSIX 
> "hack", that is the set up of the SO_REUSEADDR option on the socket to 
> bind two successive outbound connections on the same local endpoint. 
> This hack is controversial and thus [RFC5382] REQ-1 is subject to 
> controversy, for the following reasons: SO_REUSEADDR behavior is left 
> unspecified by POSIX. SO_REUSEADDR is generally implemented by OSes to 
> bypass the TIME_WAIT state for network servers. It violates TCP quiet 
> time, TIME_WAIT and can lead to data corruption. It should generally 
> only be used by listening servers, not client making outbound 
> connections. Its use is discouraged in production for listening 
> servers. RFC 6528.
>
> A correct way to achieve TCP port prediction (which is what [RFC5382] 
> REQ-1 is really about without saying it) without relying on POSIX 
> hacks is to require the NAT to be port-preserving. Port prediction is 
> straightforward in the case of port preservation. It also works nicely 
> with port overloading, and allows p2p applications to work without the 
> need of a third party public server for each TCP communication 
> instantiation. Thus it allows NAT traversal for fully decentralized 
> p2p applications. Most NATs in the wild implement TCP port 
> preservation for this reason.
>
>
> * End of page 8
>
> The external references provided point to a website written only in 
> japanese. It would be nice to provide a pointer to the english version 
> of these web pages.
>
Thanks for pointing, I should find the English page, and rewrite in next 
version of the draft.

>
>
> * 6. EIF Security
>
> Indeed, EIF poses security concerns. At the very least, use of 
> Address-Dependent Filtering should be recommended. Applications 
> requiring EIF to function are clearly badly designed and it is not the 
> role of an RFC to support incorrect designs.
>
>
> * 7. EIF Protocol Independence
>
> Do you have any reasonable use for this? In other words, a situation 
> where to punch a UDP hole in a NAT, you want to send a TCP SYN first? 
> (If that's the case, why not sending a UDP packet instead of a TCP 
> SYN...?).
> If not, it would be cleaner in my opinion to leave this requirement 
> out. If yes, it would be nicer to describe the real-world use, as i'm 
> sure most of us are not familiar with it.
>
>
> * 8. EIF Mapping Refresh
>
> (This really only applies to UDP. For TCP, NATs simply keep the 
> mapping as long as the connection is considered on from TCP point of 
> view.)
>
> Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. 
> It would be better to recommend Address-Dependent Filtering and 
> Address-Dependent mapping refreshes.
>
>   8.1 Agreed, this point has definitely been overlooked too by RFC5382
>
>
> * 9. EIM Protocol Independence
>
> Agreed
>
>
>
> * 11. Port Randomization
>
> Agreed, although it doesn't alleviate the fact the port randomization 
> should be implemented by the client OS in the first place. The NAT 
> role is not to harden TCP security.
> And as you note, this cannot be implemented if the NAT is TCP port 
> preserving, which makes up the majority of NATs in the wild.
>
>
>
> --
>
> /Ivan C./
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave


-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [e-mail]
TEL: [phone]
----------------------------------------