Subject: [BEHAVE] Review of draft-ietf-behave-p2p-state-02

From: Eric Rescorla <[email-masked]>
Date: Fri, 09 Mar 2007 08:57:02 -0800

$Id: draft-ietf-behave-p2p-state-02-rev.txt,v 1.1 2007/03/05 19:15:29 ekr Exp $

BACKGROUND
This document is a survey of techniques used by various peer-to-peer
applications to traverse NAT devices.

GENERAL COMMENTS
The use of the term "peer-to-peer" is not particularly helpful here.
First, it has negative connotations due to its association with
filesharing protocols. Second, these techniques are useful even
in applications which are not classically P2P.

The discussion of the various abstract techniques seems to be weirdly in
a vacuum, with the discussions of the concrete techniques (ICE, STUN)
relegated mostly to a "Recent Work" section. Since a number of these
protocols have been or are standardized in IETF, it would be far
more appropriate/useful to discuss them directly.

The diagrams are way too dense and quite hard to read. IMO the 
problem here is that the topologies and the messages are
intermixed. I would use separate topologies and ladder diagrams.

The concept of P2P-friendly strikes me as negatively useful. Either
it's synonymous with Address-Independent Mapping or it doesn't
appear to be operationally defined. In either case, I don't see
the point of introducing the term.

DETAILED COMMENTS
S 2.
   Readers are urged to refer [NAT-TERM] for information on NAT
   taxonomy and terminology. Traditional NAT [NAT-TRAD] is the most
   common type of NAT device deployed. Traditional NAT has two main
   variations - Basic NAT and Network Address Port Translator (NAPT).
   Of these, NAPT is by far the most commonly deployed NAT device. NAPT
   allows multiple internal hosts to share a single public IP address
   simultaneously. When an internal host opens an outgoing TCP or UDP
   session through a NAPT, the NAPT assigns the session a public IP
   address and port number so that subsequent response packets from
   the external endpoint can be received by the NAPT, translated, and
   forwarded to the internal host. Unless specified otherwise, the 
   term NAT in this document simply refers to Traditional NAT.

This seems awkward. We're concerned almost exclusively with 
NAPT, so why the term Traditional NAT? Are there sections
of the document where we're *not* using NAT to refer to Traditional
NAT.

S 2.1.
   An endpoint is a session specific tuple on an end host. An endpoint
   may be represented differently for each IP protocol. For example,
   a TCP session endpoint is represented as a tuple of (IP Address,
   TCP port), and a UDP session endpoint is represented as a tuple
   of (IP Address, UDP Port).

Wouldn't it be simpler to just say (IP address, UDP/TCP port)?

S 2.2.
I think some consistent terminology would help here. In S 2 you write:

   simultaneously. When an internal host opens an outgoing TCP or UDP
   session through a NAPT, the NAPT assigns the session a public IP
   address and port number so that subsequent response packets from
   the external endpoint can be received by the NAPT, translated, and
   forwarded to the internal host. 

Here the term "external endpoint" seems to mean the machine out on
the Internet you're talking to.

Then in S 2 you write:

   When a host in a private realm initiates an outgoing session to a
   host in the public realm through a NAT device, the NAT device
   assigns an external endpoint to translate the private endpoint so

And the "external endpoint" appears to be the transport address on the
exterior of hte NAT. This is confusing--and occurs throughout the
doc.

S 2.3.
Isn't this section duplicative of definitions in RFC 4787? 

The paragraph here would be better as a bulleted list.

Why are you referring to "Cone" NATs here? These terms are deprecated.

Given how close the IP addresses are here, maybe break up the port
#s into two ranges to help readability.

S 2.4.
Isn't this also duplicative.

This would be better as bullets.

S 2.7.
   A P2P application is an application that uses the same endpoint to
   initiate outgoing sessions to peering hosts as well as accept
   incoming sessions from peering hosts.

Hmm... DNS often initiates zone transfers from port 53. 

S 2.8.
I'm not sure "NAT-friendly" is that helpful a term:

1. In many cases people are trying to workaround the NAT. Holepunching
   isn't really "friendly"
2. I'm not sure the definition is actually correct:

   A NAT-friendly P2P application registers with a well-known
   rendezvous server, used for node registration and peer node
   discovery purposes. Pursuant to registering with rendezvous 
   server, a P2P-friendly application uses its private endpoint, 
   public endpoint, or a combination thereof to establish peering
   sessions.

One could imagine doing a DHT-based P2P app which registered with
dynamic rather than well-known rendezvous servers and it would still
traverse NATs just fine.

S 3.2.
   10.0.0.1 is not a publicly routable IP address. In the second case,
   the TCP SYN request from B will arrive at NAT A directed to port
   62000, but NAT A will reject the connection request because only
   outgoing connections are allowed.

This seems to rely on some unstated assumptions about this NAT.

   If the NAT device employs Endpoint-Independent Mapping, the public
   Client can contact external server S to determine the specific
   public endpoint from which to expect Client-A originated 
   connection. That would be P2P-friendly. However, if the NAT device

What does "that" refer to?

S 3.3.1.
The registry messages here don't seem to do anything very useful.

S 3.3.2.
It seems extremely strange not to discuss ICE--the protocol that
the IETF is standardizing to do this job--in this section.

S 3.3.4.
This section doesn't seem to me to add much.

S 3.4.
You need to add some sort of bridge here to the fact that you're
now talking about TCP.

   In particular, if the NAT device has just
   recently seen and transmitted an outgoing SYN packet with the same
   addresses and port numbers, then it will consider the session
   active and allow the incoming SYN through. If clients A and B can

Well, maybe. Some firewalls certainly don't do all this and there's no
requirement that NATs do so either... You could, for instance, look
for the ACK bit..

S 3.5.
It's probably worth explaining here why the sequence is predictable,
namely that ports are assinged in sequence. It would probably also
help to break the second para into a list.

   Since in practice a P2P application implementing this trick would
   still need to work even when one of the NATs employ 
   Endpoint-Independent Mapping, the application would need to detect
   beforehand what kind of NAT is involved on either end and modify its
   behavior accordingly, increasing the complexity of the algorithm and
   the general brittleness of the network. 

How does this happen?

S 3.6.
   This is a variant of the "Simultaneous TCP open" technique that
   allows peer-to-peer TCP sessions to be created in the presence of
   some NATs employing Address-Dependent Mapping.

Yes? You need to explain what the variiant is.

   Unfortunately, this trick may be even more fragile and timing-
   sensitive than the UDP port number prediction trick described 
   earlier. First, even as both NAT devices implement 
   Endpoint-Independent Mapping on the TCP traffic, all the same
   things can go wrong with each side's attempt to predict the public
   port numbers that the respective NATs will assign to the new
   sessions can happen with TCP port prediction as well.

I don't understand this sentence.

S 4.
   The results indicate that UDP hole punching is widely
   supported on more than 80% of the NAT devices, whereas TCP hole
   punching is supported on just over 60% of the NAT devices tested.

The word "supported" seems strange here. Rather, it works, but it's
not clear that the support is explicit.

The discussion of the various concrete techniques should be moved to the main
text.

S 5.2.
   NATs Employing Endpoint-Dependent Mapping gained popularity with
   client-server applications such as web browsers, which only need to
   initiate outgoing connections. However, in the recent times, P2P

I'm not sure what this sentence is trying to say. Endpoint-Dependent
mapping wasn't necessary for Web browsers, just that it wasn't a 
problem.

S 5.4.
This sectin appears to be weirdly quasi-normative in terms of suggesting
that NATs behave a certain way. Is that consistent with the purpose of
this document?

S 6.1.
Somewhere shouldn't this say you should be using crypto?

S 6.2.
Again, this section seems semi-normative.

Also, some mention of ICE as a defense against this semes appropriate.

-Ekr

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 12 Mar 2007 05:19:24 -0700 (PDT)

Eric,

Thank you for your comments. Please see my responses inline. 

regards,
suresh

> in applications which are not classically P2P.
[suresh] There is precedence to using the term "peer-to-peer" in prior behave
documents including the most recently published RFC - RFC 4787. 

> more appropriate/useful to discuss them directly.

[suresh] The document discusses the techniques first. The use of these
techniques is reviewed under "Recent Work" section. I will be happy to expand
more on the IETF protocols (STUN and ICE), if you like.

> intermixed. I would use separate topologies and ladder diagrams.

[suresh] I do not understand what you mean by "the topologies and the messages
are intermixed" and "use separate topologies and ladder diagrams". What did you
mean by "Topology", "message" and "ladder diagram" here?

> the point of introducing the term.

[suresh] "P2P-friendly NAT" is used to refer a "NAT employing Endpoint
Independent Mapping". I could get rid of the term "P2P-friendly NAT" entirely
and simply replace this with "NAT employing Endpoint-Independent Mapping", if
that works better for you.

> NAPT, so why the term Traditional NAT? 

[suresh] The techniques are not exclusive to NAPT. The techniques apply to both
"Basic NAT" and "NAPT". Hence the reference to traditional NAT.

>                                        Are there sections
[suresh] The sentence "Unless specified otherwise, the term NAT in this
document simply refers to Traditional NAT" is a customary way to cover the case
where the text might evolve to refer other types of NAT. For example, I do
refer to "Twice NAT" in the text. 

> Wouldn't it be simpler to just say (IP address, UDP/TCP port)?
[suresh] Yes, That would be right for a TCP/UDP session. I will simplify the
text. Thanks.

> the Internet you're talking to.
[suresh] Yes.

> exterior of hte NAT. This is confusing--and occurs throughout the
[suresh] OK, I will use "public endpoint" to refer NAT assigned public
endpoint. The above text will read now as follows. I will fix the text
accordignly wherever there is this potential confusion. 

    When a host in a private realm initiates an outgoing session to a
    host in the public realm through a NAT device, the NAT device
    assigns a public endpoint to translate the private endpoint so

> Isn't this section duplicative of definitions in RFC 4787? 
[suresh] No. I restate the definition from RFC 4787 and illustrate with an
example.

> The paragraph here would be better as a bulleted list.
[suresh] How do you mean?

> Why are you referring to "Cone" NATs here? These terms are deprecated.
[suresh] OK. I will get rid of the reference.

> #s into two ranges to help readability.
[suresh] I am not sure I understand the comment. What do you mean by IP
addresses being close? These are RFC 3330 addresses (Please see my comment at
tahe start of section 2). I do not follow your comment about breaking port #s
into two ranges.

> This would be better as bullets.
[suresh] I reuse definitions from RFC 4787 to define this term and illustrate
with an example.

> Hmm... DNS often initiates zone transfers from port 53. 
[suresh] SO, what is your comment here? Are you sayig that DNS-server shoudl be
termed a P2P application, even as it has outgoignand incoming sessiosn on the
same port?

> dynamic rather than well-known rendezvous servers and it would still

[suresh] Any rendezvous server in the public domain has to be known apriori to
the application. It doesnt matter whether it learns the address of rendezvous
server statically or dynamically. Are you objecting to the use of the wording
"well-known rendezvous server"? Would it work for you if I replaced the text
with "public domain rendezvous server" instead?

> This seems to rely on some unstated assumptions about this NAT.
[suresh] A Tradtional NAT rejects incoming sessions. There is no other
assumption here.  

> What does "that" refer to?
[suresh] Ability of client B to know the public Endpoint of client A from which
a connection will be initiated.
 
> The registry messages here don't seem to do anything very useful.

[suresh] They register public endpoints for the clients in the server.
> the IETF is standardizing to do this job--in this section.
[suresh] The document discusses the general techniques involved first. In this
case, it is referign to hairpinnin and the need to register private endpoints.

When discussing ICE protocol, I will add text indicating its use of this
technique. Thanks.

> This section doesn't seem to me to add much.
[suresh] Just the caveat on where UDP hole punching fails.

> You need to add some sort of bridge here to the fact that you're
[suresh] DO you have a suggestion? Thanks.

> requirement that NATs do so either... You could, for instance, look
[suresh] The next paragraph discusses the caveats. To be more generic, I could
replace the following sentence

   Even as both
   peering nodes simultaneously initiate continued SYN retransmission
   attempts, some remote NAT devices might not let the incoming SYNs
   through if the NAT session is in end-of-session timeout state.

with:

   Even as both
   peering nodes simultaneously initiate continued SYN retransmission
   attempts, some remote NAT devices might not let the incoming SYNs
   through.

> help to break the second para into a list.

[suresh] How do you suggest I break the paragraph into a list. What you have in
mind?

>    the general brittleness of the network. 
[suresh] What are you refering to? 
 
> Yes? You need to explain what the variiant is.
[suresh] OK, I will add a few lines here.

> I don't understand this sentence.
[suresh] Essentially, the sentence says - the prediction of a public port
number your local NAT would assign could be wrong.
> not clear that the support is explicit.

[suresh] I could use the term "works", if that works for you.

> mapping wasn't necessary for Web browsers, just that it wasn't a 

[suresh] Would replacing "gained popularity" with "werent a problem" work for
you? Thanks.
> that NATs behave a certain way. Is that consistent with the purpose of

[suresh] Section 5 is merely a  summary of observations. There is no
recommendation here. This is consistent with the purpose of this document.

> Somewhere shouldn't this say you should be using crypto?
[suresh] Sure. I will add that.

> Also, some mention of ICE as a defense against this semes appropriate.
[suresh] OK.

Thanks.

regards,
suresh

---

From: EKR <[email-masked]>
Date: Fri, 16 Mar 2007 00:10:29 -0700

> documents including the most recently published RFC - RFC 4787. 

Yeah, there's a difference between using the term 6 times in a 
document and having it as the title of the document and using
the term "P2P-friendly", etc.

> [suresh] The document discusses the techniques first.

Yes, that's what I'm complaining about. They should be discussed in
context.

> mean by "Topology", "message" and "ladder diagram" here?

I mean that the diagrams contain pictures of the network topology
as well as a bunch of things with arrows and address endpoints that
I guess represent sessions. It would be better to have those removed
from the diagram and have separate ladder diagrams (see, for instance,
RFC 3261 fig 1) to indicate the dataflow.

> that works better for you.

Yes, that would be an improvement.

> "Basic NAT" and "NAPT". Hence the reference to traditional NAT.

Yes, but most NATs now are NAPT, right? So, this distinction doesn't
seem to be doing much work...

> refer to "Twice NAT" in the text. 

It seems to me that twice NAT is orthogonal to "traditional NAT" versus
NAPT. Have I missed something?

>     assigns a public endpoint to translate the private endpoint so

And you'll call public endpoints on machines that are Internet
accessible "external addresses"? Or...

> [suresh] No. I restate the definition from RFC 4787 and illustrate with an

Yeah, I think this should be trimmed.

> [suresh] How do you mean?

I mean that it's a mass of text that I think would read better as
a broken out list of text.

> tahe start of section 2). I do not follow your comment about breaking port #s

I mean that since the IP addresses all come from the same /.24, it's
a little confusing to have say (A.1234 be talking to S1.1235). I would
make all the clients have (say) 1-1000 and all the servers have (say)
20000-21000.

> [suresh] I reuse definitions from RFC 4787 to define this term and illustrate

Yeah, again I think this is redundant.

> termed a P2P application, even as it has outgoignand incoming sessiosn on the

No, I'm saying that this definition is broken because it says that
DNS is a "P2P application" even though that doesn't match standard
terminology.

> with "public domain rendezvous server" instead?

"Publicly addressable" seems appropriate.

> a connection will be initiated.

Yeah, I sort of got that. My point was that this should be in the text.

> [suresh] They register public endpoints for the clients in the server.

I meant that they don't do anything useful in the explanation in
the text so that I would remove them for pedagogical clarity

> case, it is referign to hairpinnin and the need to register private endpoints.

Yes, I think you should integrate the ICE discussion here.

> [suresh] Just the caveat on where UDP hole punching fails.

Maybe you can integrate it into some other section.

> [suresh] DO you have a suggestion? Thanks.

Not sure what you mean. The point is that you just transition
from UDP to TCP without warning. Add a paragraph that says
that you're now going to talk about TCP.

>    attempts, some remote NAT devices might not let the incoming SYNs

How about softening the offending sentence instead.

> [suresh] How do you suggest I break the paragraph into a list. What you have in

   - NAT A has assigned its own UDP port 62000 to the communication
   session between A and S.
   - NAT B has assigned its port 31000 to
   the session between B and S. 
   - By communicating with server S, A
   and B learn each other's public IP addresses and port numbers as
   observed by S. 
   - Client A now starts sending UDP messages to port
   31001 at address 192.0.2.254 (note the port number increment), and
   client B simultaneously starts sending messages to port 62001 at
   address 192.0.2.1. 

   If NATs A and B assign port numbers to new
   sessions sequentially, and if not much time has passed since the
   A-S and B-S sessions were initiated, then a working bi-directional
   communication channel between A and B should result. A's messages 
   to B cause NAT A to open up a new session, to which NAT A will 
   (hopefully) assign public port number 62001, because 62001 is next
   in sequence after the port number 62000 it previously assigned to
   the session between A and S. Similarly, B's messages to A will
   cause NAT B to open a new session, to which it will (hopefully)
   assign port number 31001. If both clients have correctly guessed
   the port numbers each NAT assigns to the new sessions, then a
   bi-directional UDP communication channel will have been 
   established as shown in figure 9.

> [suresh] What are you refering to? 

How does the application detect beforehand what kind of NAT is involved.

> number your local NAT would assign could be wrong.

Can you please rewrite to make that clear.

> [suresh] I could use the term "works", if that works for you.

That's fine.

> [suresh] Would replacing "gained popularity" with "werent a problem" work for

Sure.

> recommendation here. This is consistent with the purpose of this document.

Well, except that you say "should not assume", etc... That's quasinormative.

-Ekr