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

From: "Francois Audet" <[email-masked]>
Date: Sun, 10 Jul 2005 12:21:28 -0700 (PDT)

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: David Barrett <[email-masked]>
Date: Sun, 10 Jul 2005 23:41:59 -0700 (PDT)

Francois Audet wrote:

If there is anything SPECIFIC that is not clear, let me know.
I agree, the BEHAVE draft defines a specific lexicon.  However, having 
the language is only half the problem.  Compelling NAT vendors to use it 
in a standardized fashion is the other half.

For example, it wouldn't be enough for scientists to merely define a 
language for nutrition.  Rather, it takes the FDA to mandate that labels 
must *use* the language in a standardized form in order for consumers to 
benefit from it.

In our case, I'd like the IETF to recommend that NAT vendors label their 
products in a consistent fashion, using the BEHAVE terminology.  BEHAVE 
defines the language; let's go the extra step and recommend that NAT 
vendors actually use it, so consumers can benefit from it.

-david

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 11 Jul 2005 06:24:58 -0700 (PDT)

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

---

From: Saikat Guha <[email-masked]>
Date: Mon, 11 Jul 2005 11:33:51 -0700 (PDT)

On Mon, 2005-07-11 at 06:24 -0700, Pyda Srisuresh wrote:
> For

Not sure about UDP, but I do see such behavior for TCP. In particular I
see:

NB=I,EF=I         5%
NB=I,EF=A        10% 
NB=I,EF=ADP      55%
NB=ADP,EF=I       2%
NB=ADP,EF=ADP    12%
NB=P,EF=I         1% 
NB=P,EF=ADP       3%

see the STUNT result page for more details. For TCP at least,
"Symmetric" subsumes 5 or more different types of NAT and is therefore
unable to distinguish between them.

-- 
Saikat
Attachment:
signature.asc