Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 9 Mar 2005 17:27:04 -0800 (PST)

First off, Much thanks to Jonathan for clearing this up about the terminology
on Symmetric NAT & Cone NATs. 

As Dan points out, these terms are already out there in use by NAT endors and
NAT users. We need clarification of these terms, not abandon them completely.
Joanthan is dropping these terms from 3489bis. If we abandon the terms
entirely, we will need to coin new terms. Given the wide use of these terms, I
suggest we redefine these terms accurately in the behave-gen draft. All behave
drafts will refer the definition provided in the gen draft for these terms. 

Any comments? Thanks.

regards,
suresh

--- Dan Wing <dwing@xxxxxxxxx> wrote:
> I believe you still need a definition of symmetric (or whatever term 
> you'd like to use) to explain the type of NAT that doesn't work with 
> STUN.  Perhaps the term non-STUN-friendly is sufficient, though?
> 
> -d
> 
> On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote:
> 
> > During the behave meeting at this IETF, we had a lengthy and not too 
> > productive debate about the precise meaning of symmetric NAT. The 
> > current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines 
> > the terms for the various NAT types. The new udp-behave draft spends 
> > some time, in section 6, trying to map the new definitions in 
> > udp-behave with the definitions in rfc3489.
> >
> > I think that this serves no purpose.
> >
> > The behave drafts are clear, I think, that the terminology in RFC3489 
> > was problematic, and that it was better to define a set of orthogonal 
> > behaviors that could be named. Thus, I think that it is a futile 
> > exercise to try and go back and clarify what we mean by "symmetric 
> > nat" by mapping the new behaviors in udp-behave to the concepts in 
> > 3489.
> >
> > I would instead propose that:
> >
> > 1. we remove the definitions of 
> > symmetric/full-cone/port-restricted/etc. from rfc3489bis. These 
> > definitions are not used anymore except for the IAB considerations 
> > section, where they are not really needed.
> >
> > 2. We remove all the stuff in behave-udp that tries to give new 
> > meaning to those terms
> >
> > 3. behave-udp update its references to rfc3489bis whenever it needs to 
> > mention stun
> >
> > Comments?
> >
> > -Jonathan R.
> >
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Director, Service Provider VoIP Architecture   Parsippany, NJ 
> > 07054-2711
> > Cisco Systems
> > jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 9 Mar 2005 18:07:04 -0800 (PST)

I don't think it is our objective to obliterate the definition from the 
world's vocabulary. It is our objective to define sufficient terminology 
to convey the requirements we need to convey in the documents we are 
trying to produce. I believe the terminology defined in the udp-behave 
draft, which uses terms for each individual component behavior, is the 
ideal way to do that. The fact that we cannot agree on what a symmetric 
NAT is, merely elucidates that point.

-Jonathan R.

Pyda Srisuresh wrote:

Any comments? Thanks.

regards,
suresh

-d

Comments?

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 9 Mar 2005 19:36:37 -0800 (PST)

--- Jonathan Rosenberg <jdrosen@xxxxxxxxx> wrote:

> world's vocabulary. 

[suresh] What I am saying is to keep the terms, but revise the definitions.
I.e., Donot obliterate the terms, but define them more precisely in another
draft, so the terms can be used with the revised definition. At this time, 
behave-nat-udp draft and  srisuresh-behave-p2p-state use these terms. Even if 
behave-udp draft can do away with the terms, these terms have use in
srsuresh-behave-p2p-state draft.    

>                     It is our objective to define sufficient terminology 
> ideal way to do that. 

[suresh] Sure. When use of these terms are not necessary, using different set
of terminology to carry the same intent seems reasonable. 

>                       The fact that we cannot agree on what a symmetric 

[suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is
problematic. But, that is not to say, we cannot fix it. Here is a suggestion
for revised definitions. Please comment if the following revised definitions
meet the intent. Thanks.

Symmetric NAT - A variation NAPT that does NOT use port binding for TCP/UDP
sessions originating from private hosts. If a TCP/UDP endpoint on a private
host, denoted by the tuple of (IP address, port no), originated multiple
sessions, a new public TCP/UDP port is assigned to translate the private
endpoint in each new session.

Port Restricted Cone NAT - A variation of NAPT that uses Port Binding for
TCP/UDP sessions originating from private hosts and would permit packets in the
inbound direction for just the sessions the private host had initiated. If a
TCP/UDP endpoint on a private host, denoted by the tuple of (IP address, port
no), originated multiple sessions, the same public TCP/UDP port is assigned to
translate the private endpoint in each new session. Further, only the packets
that belong to the sessions initiated by the private host are permitted on the
inbound.

Address Restricted Cone NAT - A variation of NAPT that uses Port Binding for
TCP/UDP sessions originating from private hosts, but differs in how it permits
inbound UDP packets from Port Restricted Cone NAT as follows. Subsequent to
creating a UDP port binding for an endpoint on a private host,
Address-restricted Cone NAT will accept incoming UDP packets to the
corresponding public port from only those external endpoints whose IP address
match the address of external endpoint to which the private endpoint had
initiated outgoing sessions.

Full Cone NAT - A variation NAPT that uses Port Binding for TCP/UDP sessions
originating from private hosts, but differs in how it permits inbound UDP
packets from Address/Port Restrictd Cone NATs as follows. Subsequent to
creating a UDP port binding for an endpoint on a private host, Full Cone NAT
will accept incoming UDP packets to the corresponding public port from any
external endpoint.

regards,
suresh

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Mar 2005 01:25:26 -0800 (PST)

inline.

Pyda Srisuresh wrote:

[suresh] What I am saying is to keep the terms, but revise the definitions.
I.e., Donot obliterate the terms, but define them more precisely in another
draft, so the terms can be used with the revised definition. At this time, 
behave-nat-udp draft and  srisuresh-behave-p2p-state use these terms. Even if 
behave-udp draft can do away with the terms, these terms have use in
srsuresh-behave-p2p-state draft.  
That is a separate issue; this is your own individual draft - you are 
free to put whatever text you want in it. If we agree that none of the 
documents the group is working on are require the definition, then we 
can move on.

[suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is
problematic. But, that is not to say, we cannot fix it. Here is a suggestion
for revised definitions. Please comment if the following revised definitions
meet the intent. Thanks.
Our solution to fix it was to recognize that it would be better to 
define NATs based on specific behavioral axes, which are spelled out and 
more rigorously defined in the udp-behave draft.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Mar 2005 17:32:51 -0800 (PST)

On 3/9/05 9:36 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is

not as chair.

I find all these definitions horribly under specified and there has been
many many emails discussing that we don't have common agreement on terms
like binding. The terminology that is in the current drafts is understood
and was selected because it was stuff that people did agree on the meaning
of it. Unless we find a need to define these terms, I see it as a long and
frustrating exercise with no strong benefit when it is done.