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

["Reinaldo Penno (repenno)" <[e-mail]>]

Hi Ivan,

Thanks for the detailed review of the draft. You might want to reference the newer version at  http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00

I'm going through your comments and will start a discussion shortly.

Thanks,

Reinaldo

From: ivan c <[e-mail]<mailto:[e-mail]>>
Organization: cacaoweb
Reply-To: <[e-mail]<mailto:[e-mail]>>
Date: Sun, 16 Jun 2013 21:14:16 +0200
To: <[e-mail]<mailto:[e-mail]>>
Subject: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis


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.


* 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.
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.


* 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]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/behave