ivan c
2013-06-16 19:14:16 UTC
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
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