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

Kengo Naito <> Tue, 18 June 2013 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED73C21F9E63 for <>; Mon, 17 Jun 2013 21:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.089
X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C5AnGN+cvisF for <>; Mon, 17 Jun 2013 21:57:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C1BC21F9E02 for <>; Mon, 17 Jun 2013 21:57:00 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id r5I4ugI7016564; Tue, 18 Jun 2013 13:56:42 +0900
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id D567DE0155; Tue, 18 Jun 2013 13:56:42 +0900 (JST)
Received: from ( []) by (Postfix) with ESMTP id C9551E014E; Tue, 18 Jun 2013 13:56:42 +0900 (JST)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id r5I4ueDf028739; Tue, 18 Jun 2013 13:56:41 +0900
Message-ID: <>
Date: Tue, 18 Jun 2013 13:56:54 +0900
From: Kengo Naito <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020003090909030907050509"
Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jun 2013 04:57:06 -0000

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 
> <>, 
> 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.
> * 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 ? This alternative do not rewrite 
timestamps nor ISNs.
Also, I do not intend to make "must", this is only one of 

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

NTT Network Technology Laboratories
Kengo Naito
TEL: +81 422-59-4949