Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 1 Mar 2007 06:15:39 -0800 (PST)

--- Cullen Jennings <[email-masked]> wrote:

> 
> On Feb 28, 2007, at 7:46 AM, Pyda Srisuresh wrote:
> 
> > Note, this is different from "Behave Compliant NAT". If you like, I
> > could add a line that BEHAVE complaint NAT devices are good  
> > examples of "P2P
> > friendly NAT" devices.
> 
> Help me understand the difference between the two? If this is an  
> effort to define P2P Friendly NATs to be the things that the WG  
> disagreed with you about when doing the existing drafts, I doubt that  
> represents WG consensus.
> 

[suresh] Cullen - I have no intent to do anything outside WG consensus in any
draft, including the p2p-state draft. And, I had not done this before.

The term "P2P-friendly NAT" is defined in p2p-state draft as follows.

   A P2P-friendly NAT is a NAT device that maintains the endpoint
   identity of a P2P host application when the P2P application
   initiates a session. P2P-friendly NAT devices permit traversal of
   P2P applications traffic across themselves. NAT devices employing
   Address-Independent Mapping are examples of P2P-friendly NAT
   devices.

As you can see the only requirement attributed to this term is
Endpoint-Independent mapping. This draft is focused solely on NAT traversal for
p2P applications. Whereas, RFC 4787 and TCP/ICMP Behave drafts are more
holistic and have a total of 32 (14+9+9) requirements for BEHAVE compliance.
For example, they each have mandatory timeout requirement that many NATs out
there do not comply with yet.

This is why I said that the term "P2P Friendly NAT" is different from "Behave
Compliant NAT". Hope you understand.

regards,
suresh 

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

---

From: Saikat Guha <[email-masked]>
Date: Thu, 01 Mar 2007 13:21:33 -0500

> there do not comply with yet.

Just made a quick pass through the document, three comments.

1) In the definition of P2P-Friendly, any particular reason why the
other BEHAVE requirements are left out? For example, a NAT that
instantly responds with a RST packet to any and all inbound-SYN packets
is _not_ P2P friendly even if it had endpoint independent mappings.
According to the current definition, it would be classified as P2P
friendly.

2) The document currently does not talk about keepalive packets. IMHO
keepalives should be in scope, particularly since datapath
authentication is (advocated in section 6.1). P2P developers must
perform both datapath auth and keepalives in NAT'ed environments.

3) The document defines Endpoint-Dependent mapping and filtering, as has
been pointed out to basically refer to *non*-Endpoint-Independent
mapping and filtering defined in BEHAVE documents. Instead of defining
new terms, suggest using negated versions of established terms.

2c
-- 
Saikat

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 2 Mar 2007 06:29:41 -0800 (PST)

> Just made a quick pass through the document, three comments.
[suresh] Thank you for your comments.
 
> According to the current definition, it would be classified as P2P
 
[suresh] Saikat - The scope of the draft is restricted to describing techniques
used to set up 2-way communication between endoints of a peer-to-peer
application. No discussion of timeouts, RST processing, keepalives, fragment
handling etc. That is not what the draft is about. Given the restricted scope,
the definition of "P2P-friendly NAT" is apt to be restricted to mere Endpoint
Independent Mapping.

Whereas, the scope of BEHAVE drafts is a holistic description of requirements
on NATs from the perspective of complete life-cycle of end-to-end connections.
BEHAVE drafts for TCP, UDP and ICMP do not talk about the use of rendezvous
servers, Relay servers, port-predition and the like in setting up 2-way
communication. Nonetheless, the requirements laid out in the BEHAVE drafts lend
themselves to supporting the 2-way communication across NATs. 

You might say, a "BEHAVE-compliant NAT" adheres to  "Necessary and sifficient"
requirements for a hollistic operation of all applications, including P2P;
whereas a "P2P Friendly NAT" merely states the requirement ("Necessary, but not
sufficient") for seting up end-to-end connection between P2P applications.

> perform both datapath auth and keepalives in NAT'ed environments.

[suresh] Please see my note above. The scope is restricted to settign up 2-way
communication. Not, beyond that.

> new terms, suggest using negated versions of established terms.

[suresh] Saikat - "Non-Endpoint-Independent Maping" is no less of a new term
than "Endpoint-Dependent Mapping". Endpoint Dependent Mapping is easy to read
and simply reuses defintions from RFC4787.

regards,
suresh