Subject: [p2p-sip] Request for comments on draft-srisuresh-behave-p2p-state-03.txt

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Wed, 12 Jul 2006 06:53:01 -0700 (PDT)

Folks,

The authors of draft-srisuresh-behave-p2p-state-03.txt wish to submit the draft
as independent submission to the RFC editor and request its publication as an
informational RFC. Please review and let us know your comments by no later than
07/26/06. I.e., within 2 weeks from now. Thanks.

The draft is available in the archives as follows.
http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-03.txt

regards,
suresh

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 12 Jul 2006 11:20:35 -0400

Is this a request for people on the BEHAVE and P2P-SIP mailing lists
to review the draft and send you comments?

- Philip

On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote:

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Wed, 12 Jul 2006 09:34:41 -0700 (PDT)

Right. Thanks.

regards,
suresh

---

From: dwing at cisco.com (Dan Wing)
Date: Wed, 12 Jul 2006 14:17:42 -0400

During the PROTO (*) writeup, we decided that review of this document by
BEHAVE and P2P-SIP would be useful, as both groups have subject matter
experts in the area covered by this draft.  The abstract of
draft-srisuresh-behave-p2p-state-03.txt is:

   This memo documents the various methods known to be in use by the
   peer-to-peer (P2P) applications for communication in the presence
   of Network Address Translators (NATs) at the current time. This
   memo covers NAT traversal approaches used by both TCP and UDP
   based applications. This memo is not an endorsement of the methods
   described, but merely an attempt to capture them in a document.

(*) PROTO:  draft-ietf-proto-wgchair-doc-shepherding-07.txt

-d

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] 
> Sent: Wednesday, July 12, 2006 12:35 PM
> To: Philip Matthews
> Cc: ietf-behave at list.sipfoundry.org; p2p-sip at cs.columbia.edu; 
> dwing at cisco.com; Dan Kegel
> Subject: Re: [Ietf-behave] Request for comments on 
> draft-srisuresh-behave-p2p-state-03.txt
> 
> Right. Thanks.
> 
> regards,
> suresh
> 
> > > informational RFC. Please review and let us know your 
> comments by  
> > > no later than

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Wed, 26 Jul 2006 22:08:42 -0400

A few comments that came to mind while doing a quick read-through of
this document:

- I would really rather see the more current BEHAVE terminology used
in this draft.  Even though it's not yet official in an RFC, I think
it will confuse people to see the older terminology used.

- It would be nice to see a discussion of what standards are being
developed to try to implement these techniques (e.g. which are
supported by Teredo and ICE).  I think the more recent ICE draft is
written to imply a bit broader applicability than the previous one
was.

- I was surprised to notice that the authors did not cite their own
very good USENIX05 paper as an informative reference.

Bruce

On 7/12/06, Dan Wing <dwing at cisco.com> wrote:
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Thu, 27 Jul 2006 08:36:12 -0700 (PDT)

Thanks, Bruce, for your comments. Please see my responses inline.

regards,
suresh

> it will confuse people to see the older terminology used.
[suresh] We used the RFC 3489 terminology (Symmetric NATs, Cone NATs) because
the draft is a capture of existing techniques. We felt, it made sense to use
terminology from existing RFCs to describe the current state rather than use
newer terms in Behave. I will take your advice and review the draft to see if
this can be revised to use the BEHAVE terminology. Thanks.

> written to imply a bit broader applicability than the previous one
[suresh] Right, your point is well taken. Even though, the draft does refer
both ICE and TEREDO, the coverage can be better. I will add more text
discussing the newer standards. The draft doesnt capture the newer ICE well.
ICE draft is rapidly changing from UDP only to UDP + TCP and potentially more
changes in newer revs. Oh, well..

> very good USENIX05 paper as an informative reference.

[suresh] Sure, we will do that. Thank you for your comments.

regards,
suresh

---

From: dwing at cisco.com (Dan Wing)
Date: Thu, 27 Jul 2006 12:18:12 -0700

> [suresh] We used the RFC 3489 terminology (Symmetric NATs, 
> Cone NATs) because the draft is a capture of existing techniques. 
> We felt, it made sense to use terminology from existing RFCs to 
> describe the current state rather than use newer terms in Behave.  I 
> will take your advice and review the draft to see if this can be 
> revised to use the BEHAVE terminology. Thanks.

But draft-srisuresh-behave-p2p-state-03.txt's terminology doesn't
match RFC3489's definitions.  For example, taking just 'port restricted 
cone', there is a difference:

RFC3489:

#   Port Restricted Cone: A port restricted cone NAT is like a
#     restricted cone NAT, but the restriction includes port numbers.
#     Specifically, an external host can send a packet, with source IP
#     address X and source port P, to the internal host only if the
#     internal host had previously sent a packet to IP address X and
#     port P.

draft-srisuresh-behave-p2p-state-03.txt:

#   Port-Restricted Cone NAT
#     Subsequent to establishing Port Binding at the start of an
#     outgoing TCP/UDP session, Port-Restricted Cone NAT will
#     accept incoming traffic to the corresponding public port from
#     only those external endpoints to which the internal host has
#     previously sent one or more outgoing packets. I.e., only
#     those incoming packets that belong to the sessions initiated
#     by the private host are permitted on the inbound.

"only those external endpoints" means IP address, but I expect your
intent was to capture both the external endpoint (IP address) and
external port.  

A lot of pain resulted in the consensus text in RFC3489; if you
want to use those old terms, I would strongly encourage adopting
the definitions from RFC3489 using exactly the same text as in
RFC3489 itself.  Similarly, if you want to adopt the new terms,
it would be best to copy the text verbatim.

-d

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Thu, 27 Jul 2006 14:07:34 -0700 (PDT)

> intent was to capture both the external endpoint (IP address) and

[suresh] Dan - Early on, in the terminology section, the endpoint is referred
as  the tuple of (IP adress, Port). This is how the endpoint is referred
throughout the documnt, including the figures (all 9 of them). The notation
used in the figures to represent the endpoint is <IP address>:<Port>. Endpoint
is not referred as just an IP address, anywhere in the document. However, I
could make endpoint  semantics more explicit be definig this as a term.

The same endpoint semantics are used even when defining "Address-Restricted
Cone NAT" and "Full Cone NAT".

Address-Restricted Cone NAT
      Subsequent to establishing Port Binding at the start of an
      outgoing UDP session, Address-Restricted Cone NAT will accept
      incoming UDP traffic to the corresponding public port from
      only those external endpoints whose IP address match the
      address of a node to which the internal host has previously
      sent one or more outgoing packets.

Full Cone NAT
      Subsequent to establishing Port Binding at the start of an
      outgoing UDP session, a full cone NAT will accept incoming
      UDP traffic to the corresponding public port from ANY
      external endpoint on the public network. Full cone NAT is
      also sometimes referred as "Promiscuous NAT".

> RFC3489 itself. 

[suresh] There is ambiguity in RFC 3489 definitions. Hence the reason for
disambiguating the terms by using  illustration figures and additional text.
For example, the p2p-state text describes that "Port-Restricted Cone NATs" are
applicable to both TCP and UDP sessions. But, that "Address-Restricted Cone
NAT" and "Full COne NAT" are specific to UDP only.

>                  Similarly, if you want to adopt the new terms,

[suresh] The p2p-state draft has been around for some time (circa 2004). I
believe, the draft text flows well using the terminology it has. To be honest,
I am concerned about redoing the draft using BEHAVE terminology. That could be
a big surgery and adds dependencies. UDP Behave is about to be an RFC. But, TCP
Behave is not there yet. TCP behave terms do differ from the UDP draft. 

Dan and Bruce - My preference would be to use the terms as is instead of
revising the draft with newer terms. I will be happy to make specific text
changes where something is not clear. If this is agreeable to you, please
suggest the speacific text where you see problem. Thanks.

regards,
suresh

---

From: dwing at cisco.com (Dan Wing)
Date: Thu, 27 Jul 2006 14:50:48 -0700

> [suresh] Dan - Early on, in the terminology section, the 
> endpoint is referred as  the tuple of (IP adress, Port). This is how 
> the endpoint is referred throughout the documnt, including the figures 
> (all 9 of them). The notation used in the figures to represent the 
> endpoint is <IP address>:<Port>.  Endpoint is not referred as just an 
> IP address, anywhere in the document. However, I could make endpoint 
> semantics more explicit be definig this as a term.

I don't feel the normal definition of 'endpoint' is its IP address
and UDP port.  Does 'socket' or 'endpoint socket' have the meaning 
you are ascribing to 'endpoint'?

...
> [suresh] There is ambiguity in RFC 3489 definitions. Hence 
> the reason for disambiguating the terms by using  illustration 
> figures and additional text.  For example, the p2p-state text 
> describes that "Port-Restricted Cone NATs" are applicable to both 
> TCP and UDP sessions. But, that "Address-Restricted Cone NAT" 
> and "Full COne NAT" are specific to UDP only.

Instead of clarifying a standards-track document (RFC3489) with
an informational document, I see more value in just letting the
old terms die out and be replaced with the mapping and filtering
terms in -behave-nat-udp (sections 4.1 and 5).  When RFC3489bis 
(draft-ietf-behave-rfc3489bis) is published, it will obsolete
RFC3489.  It seems useful that the only use of the terms will
soon be a document marked 'Obsoleted by' so we can adopt the 
newer and more accurate terms.

> [suresh] The p2p-state draft has been around for some time 
> (circa 2004).  I believe, the draft text flows well using 
> the terminology it has.  To be honest, I am concerned about 
> redoing the draft using BEHAVE terminology.  That could be
> a big surgery and adds dependencies. 

I agree it could be a large surgery on the document.  

I don't understand how it would add a dependency; neither Bruce
nor I suggested adding a normative reference.  Even if you
did, the normative reference would be to behave-nat-udp which 
is very close to being finished in IESG and will be a standards-
track document (so no worries about a downward reference).

> UDP Behave is about to 
> be an RFC.  But, TCP Behave is not there yet.  TCP behave 
> terms do differ from the UDP draft. 

What is the value of TCP's different terms?  I mean, does the
different terminology help or hurt understanding, consensus,
and interoperability?

> Dan and Bruce - My preference would be to use the terms as is 
> instead of revising the draft with newer terms.  I will be 
> happy to make specific text changes where something is not 
> clear.  If this is agreeable to you, please suggest the 
> speacific text where you see problem. Thanks.

The specific text where I see a problem is the use of RFC3489
terminology (cone, port restricted, symmetric) when RFC3489bis
is an active WG document and will not include that terminology.
That means, upon publication of draft-srisuresh-behave-p2p-state
as Informational, it will be the only document that uses these
soon-to-be-obsoleted terms.

-d

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Thu, 27 Jul 2006 16:17:57 -0700 (PDT)

> you are ascribing to 'endpoint'?

[suresh] I donot believe, there is a well-known definition to endpoint. The
p2p-state draft refers this as a protocol specific tuple. I will define the
term explicitly in Terminology section.
 
> newer and more accurate terms.

[suresh] I understand.

> soon-to-be-obsoleted terms.

[suresh] OK, I will try and revise the text so as not to refer RFC3489 terms.
Thanks.

regards,
suresh