Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel

From: "Francois Audet" <[email-masked]>
Date: Mon, 11 Jul 2005 09:58:02 -0700 (PDT)

We've been through this many times before, and people don't agree with
your
views on Binding vs. Mapping. It's as simple as that.

Furthermore, since the very beginning of the group, it was agreed to NOT
use 
the terminology Cone/Symmetric NAT because it is too confusing.

Last meeting, in order to satisfy YOU, I added a section on relating the
new terminology with the Cone/Symmetric terminoly. We spent the whole
meeting arguing about what Symmetric really meant.

The agreement of the last meeting was therefore to REMOVE completely the

terminology Cone/Symmetric from both the Behave document and from the 
revised-RFC3489. The rationale is what we had claimed all along: that it
is too confusing, and has too many grey areas. And this was based on a 
suggestion from the author of RFC 3489.

This is settled. You can't ignore the decisions of the group like you 
keep on doing.

Let's move on.

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Monday, July 11, 2005 06:25
> To: Audet, Francois [SC100:9T51:EXCH]; David Barrett
> Cc: Behave
> Subject: RE: [Ietf-behave] Determining the precise behavior 
> of a given NATmodel
> 
> 
> As David mentioned, I do believe, the BEHAVE drafts should 
> use standard terminology in order for the vendors to be able 
> to formalize the definition of their NAT characteristics. The 
> terms should be standard across all the RFCs they refer (at a 
> minimum, all NAT RFCs). The terminology used in the UDP draft 
> conflicts with prior NAT terminology and is problematic in 
> its current form.  
> 
> 1. The UDP draft defines the term "Address/Port Mapping" that 
> contradicts prior definition of the same term in RFC 4008 (NAT MIB).
> 
> RFC 4008 defines "Address/Port Map" as a configuration entry 
> on a NAT device. NAT device looks up the configured map 
> entries in determining translation parameters for new 
> sessions. "Address/port map" entries stay mostly unchanged 
> during the operation of a NAT device, as they are config entries.
> 
> The UDP draft, on the other hand, defines "Address/Port 
> Mapping" as assignment of a translation endpoint by the NAT 
> device for an outgoing session and is created on the fly on a 
> per-session basis. Unlike in RFC 4008, this is not a 
> configuration entry. An associated "Mapping timer" is defined 
> as the time a mapping will stay active without packets 
> traversing the NAT. The equivalent of "Address/Port Mapping" 
> and "Address/Port mapping timer" are "NAT Session" and "NAT 
> Session idle timeout" in RFC 4008.
> 
> 2. The UDP draft finds devious ways in which to work around 
> the RFC 3489 definitions for Cone and Symmetric NATs. It does 
> this by splitting NAT function into mapping and filtering 
> behaviors. It defines Address/Port mapping behavior to be one 
> of a) Endpoint independent, b) Address Dependent, c) Address 
> and Port Dependent. And, defines filtering behavior of 
> external packets to be one of a) Endpoint independent, b) 
> Address Dependent, c) Address and Port Dependent. 
> 
> In reality, a NAT device has a single instrument called "NAT 
> Session" that deals with both translation and packet 
> filtering. Only packets pertaining to an existing "NAT 
> Session" are permitted to traverse in either direction. For 
> example, there is no case, where a NAT Session uses "Endpoint 
> Indepenent mapping" and "Address dependent filtering" (or) 
> "Address dependent mapping" and "Address and Port Dependent 
> filtering".
> 
> When an external packet comes inbound to a NAT assigned 
> address/port endpoint and the exsting NAT Session does not 
> match this packet, the NAT device has to make a fresh 
> determinination on whether or not to make a new NAT Session 
> based on the orientation of the "Address/Port Binding" in 
> use. In case of NAPT, Port Bindings are outbound only and 
> will not permit creating a new inbound NAT Session. The UDP 
> draft does not use the term "Binding" or any associated terms 
> in decribign the NAT behavior.
> 
> NAT vendors ought to be able to use standard terminology such 
> as "NAT Session", "NAt Session idle timeouts", "Binding", 
> "Binding timeout" and so forth to describe the 
> characteristics of their NAT device.  
> 
> cheers,
> suresh
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > I believe the UDP draft does exactly that. It describes 
> very specific 
> > Requirements that have to be met by NAT vendors.
> > 
> > This is exactly why we got rid of fuzzy terminology like 
> > Cone/Restricted and so forth that nobody agreed on the meaning.
> > 
> > I don't see anything at this point that is not sufficiently 
> clear for 
> > NAT vendors in the udp draft.
> > 
> > If there is anything SPECIFIC that is not clear, let me know.
> > 
> > > -----Original Message-----
> > > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx]
> > > Sent: Sunday, July 10, 2005 02:12
> > > To: Pyda Srisuresh
> > > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave
> > > Subject: Re: [Ietf-behave] Determining the precise behavior 
> > > of a given NATmodel
> > > 
> > > 
> > > Pyda Srisuresh wrote:
> > > > Even within BEHAVE RFCs, there can be variation across
> > > vendors in how
> > > > they implement the same RFC. Several of the 
> requirements specify a
> > > > threshold, not the absolute value.Ex: NAT Session 
> tmeouts, Binding 
> > > > timeouts, Address-restricted Cone NAT behavior vs. Full 
> Cone NAT 
> > > > behavior, Fragmentation constraints etc.
> > > 
> > > Yes, this is precisely my concern.  I would like to see
> > > BEHAVE recommend 
> > > that NAT vendors produce a formalized definition of their NAT 
> > > characteristics -- using the BEHAVE-standardized 
> terminology in some 
> > > clearly defined, regularlized format.
> > > 
> > > Think nutritional-guides on cereal boxes; something that
> > > allows you to 
> > > look at 10 boxes side-by-side and clearly understand the specific 
> > > differences.
> > > 
> > > -david
> > > 
> > > 
> > 
> 
> 
> 
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 11 Jul 2005 12:38:15 -0700 (PDT)

> views on Binding vs. Mapping. It's as simple as that.
[suresh] Bryan and I have had numerous e-mail conversations with you and Cullen
way back in 2004 on the inconsistent use of terms in the UDP draft. That was
really the genesis of the behave-gen draft. David's comments about lack of
consistent terms to allow NAT vendors to characterize their NAT devices
triggered me to draw this to the attention of the list. 

It is clear, you still dont see what I am saying. It is not one of "Binding" vs
"Mapping". It is inconsistent use of the term "Address/port Map" and not using
the terms "NAT Session" and "Binding". Anyways, I am done tryign to convince
you. 

I posted my concerns to the list to hear if others care.

> meeting arguing about what Symmetric really meant.
[suresh] Hmm... as I recall from the last WG meeting, the explanation text you
had for Cone/Symmetric NATs in the UDP draft was more confusing than the
original definitions and you were rushing to issue a WG last call on the draft.
Someone in the meeting said one could drive a huge vehile through the holes
inthe logic. I dont recall who. Naturally, I, as with many others, in the
meeting were opposed to the text you had. 

> This is settled. You can't ignore the decisions of the group like you 
[suresh] We agreed not to use the Cone/Symmetric terminology. I am fine with
that. But, we had no agreement on the replacement text you had put in. 

For example, you say the Address Map behavior can be one of a) external Address
independent, b) Address dependent or c) Address and Port Dependent. That makes
no sense. The address Map behavior always is external Address or Port
independent, even in the case of a Symmteric NAT. What is different is the way
a "NAT Session" is setup that exhibits the Symmetric NAT vs Cone NAT behaviors.
The parameters of a NAT Session are setup using wild-card matches for Address
restricted and Full-Cone NAT. This is what characterizes the changes in
filtering across Cone vs Symmetric NAT behaviors. Symmetric NATs do not use
"Bindings". Cone NATs do. Together, "NAT Session" and "Binding" are the key
instruments in describing the NAT behavior, without ever refering the
Cone/Symmetric NAT terminology.

Instead, you chose to explain this with the use of "Address/Port Map" and
"fltering" behaviors, with 3 different possibilites for each type. You even
drew a matrix on the acceptable combinations (in rev 0). It was extremely
confusing. It is a good thing that you later removed the matrix. You strated
believing in these behavioral model so much that you even had text to refresh
the filtering behavior. I am just saying the model you had put together using
non-standard terminology is confusing to even yourself.  Given that, how do you
expect vendors to charactrize their NAT devices without standard terminology?

cheers,
suresh