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

From: ivan c <[email-masked]>
Date: Sun, 16 Jun 2013 21:14:16 +0200

Hello, 

This is my review of draft-penno-behave-rfc4787-5382-5508-bis
[1], 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._

Links:
------
[1]
http://www.ietf.org/mail-archive/web/behave/current/msg10831.html

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 17 Jun 2013 13:26:50 +0000

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 <[email-masked]<mailto:[email-masked]>>
Organization: cacaoweb
Reply-To: <[email-masked]<mailto:[email-masked]>>
Date: Sun, 16 Jun 2013 21:14:16 +0200
To: <[email-masked]<mailto:[email-masked]>>
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.

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

---

From: Kengo Naito <[email-masked]>
Date: Tue, 18 Jun 2013 13:56:54 +0900

Hi Ivan,

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

(2013/06/17 4:14), ivan c wrote:
> <http://www.ietf.org/mail-archive/web/behave/current/msg10831.html>, 
> which is indeed a step in the right direction and corrects omissions 
> 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.

> 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 
> 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.
>
>
> 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
>
> Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. 
> It would be better to recommend Address-Dependent Filtering and 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [email-masked]
TEL: +81 422-59-4949
----------------------------------------

---

From: ivan c <[email-masked]>
Date: Tue, 18 Jun 2013 18:50:48 +0200

Hi Kengo, 

See my answers interleaved below.

>  Also, I do not intend to make 3.1.2.1 "must", this is only one of

3.1.2.1 will be most definitely frowned upon. Before suggesting such
alternative, the benefits need to be quantified in terms of CGN resources
usage. Is the TIME_WAIT state really that much of an issue for CGN resource
utilization? It looks to me as a micro-optimization. Of course, this can
still be suggested as a MAY in the document (as it's an interesting idea).

3.1.2.2 I was unable to fully grasp the idea and its relationship with the
TIME_WAIT state, it would be nice if you could elaborate on this.

3.1.2.3 you're mangling with the TCP protocol itself, which is arguably
even more intrusive than mangling with so fields in the TCP header like in
3.1.2.1

3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any
reference for this?

> In
> the draft, I meant that Port overlapping behavior can only be used when
the
> 5-tupple of connections are different.

There are a few issues with the section 4. of the draft.

Quoting: "This document clarifies that this port
   overlapping behavior can be extended to connections originating from
   different interal source IP:ports as long as their destinations are
   different.  This known as EDM (Endpoint Dependent Mapping)."

No, EDM, EIM, always refer to sessions originating from the *same local
endpoint*.
Here you are describing a "port overlapping" behavior for sessions
originating from distinct endpoints. This is known as "port overloading".
EDM refers to the case where we can sometimes "break" the EIM requirement,
for example when we know it doesn't adversely affect the application (such
as with HTTP).

In your second paragraph, you clearly describe the "port overloading"
behavior. Thus, I think you should drop the "port overlapping" terminology,
replace it with "port overloading", and don't mention EDM
(Endpoint-Dependent Mapping), which is not directly related to the topic.

Port overloading does not have any bad effects. Of course, as long as the
5-tuple uniqueness is preserved by the NAT, which is a MUST in any case.
However, doing aggressive port overloading generates opportunities for
collisions, which must be dealt with by dropping a session or breaking the
EIM requirement, which is a serious problem for UDP, but not so much for
TCP. Such collision events remain rare, and it is OK to break EIM sometimes
for TCP, as the application can make a retry (using a new ephemeral local
port), that will most certainly work the second time.

I can help you develop and improve the section 4. of the draft with you if
you'd like.

Regards,
Ivan

---

From: Kengo Naito <[email-masked]>
Date: Fri, 21 Jun 2013 15:22:21 +0900

Hi Ivan,

Thanks for comments,

> still be suggested as a MAY in the document (as it's an interesting idea).
For someone who uses CGN and do not have enough ports ready can use this 
micro-optimization(3.1.2).
Ofcourse, there are other ways to handle port shortage problem(such as 
port-overloading).
So, I agree with your point that this should be suggested as MAY.
Also, we should remove 3.1.2.1 and only write 3.1.2.2.
I'll explain 3.1.2.2 below.

> TIME_WAIT state, it would be nice if you could elaborate on this.
In this mechanism, usable port set are splited to each client, which 
means that for each port,
arriving packets have monotonically increasing values of TCP timestamp 
or ISN.
In this case, as values are monotonically increasing, 6191 will work and 
terminate TIME_WAIT.

> even more intrusive than mangling with so fields in the TCP header like in
Okay.
If the last ACK getting lost is the rare case and  no bad effects 
occure,  we should remove this part.

> 3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any
Section 1. of RFC 6191 says that RFC 1122 4.2.2.13(which uses ISN to 
terminate TIME_WAIT) is included in the Linux kernel.
(RFC 1122 4.2.2.13 functuion is a part of 6191.)
Also, I checked some OSes a year ago which had RFC 1122 4.2.2.13 function.

-Linux 2.6.18(CentOS 5.6)
-FreeBSD 7.4R
-Windows 7
-MacOSX Lion

> (Endpoint-Dependent Mapping), which is not directly related to the topic.
  I understood that as you wrote below, 5-tuple uniqueness for port 
overloading is a MUST, and  that means I was trying to describe "port 
overloading".
Excuse me for my misunderstanding.
I should write "port overloading" in next revision.

> I can help you develop and improve the section 4. of the draft with you if
I'll be glad if you do so.