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

From: "Francois Audet" <[email-masked]>
Date: Sat, 9 Jul 2005 11:14:14 -0700 (PDT)

> Good.  But is there any requirement or recommendation that 
> NAT vendors 
> document their NAT's behaviors using this terminology?

No. I don't see how it would be enforceable.
I'd be very happy to see boxes with "IETF RFC XXXX, YYYY, ...."
compliant
(where XXX, YYYY are behave RFCs). Soon. Not three years from now
when everybody is still laughing at why VoIP never made it because
the IETF could put out an RFC saying "Don't do a symmetric NAT".

> For example, I'm sure Zyxel could sit down and write in 
> BEHAVE-compliant 
> terminology precisely how their NATs are supposed to... well, behave. 
> However, it doesn't appear that they have done so yet, and 
> I'm curious 
> if the BEHAVE draft will recommend to NAT vendors -- like 
> Zyxel -- that 
> in order to claim BEHAVE compliance they need to document how 
> their NATs 
> behave?

I can assure you that NAT manufacturers would very much like to have a
set
of BEHAVE RFCs guiding them. It's not like they are trying to do the 
wrong thing on purpose.

> 
> > We also have on the Charter as an item of "Produce a BCP 
> document that
> > describes the usage of protocols like STUN for performing black-box 
> > testing and characterizing NAT behavior".
> 
> Ah, now this would be great.  I'm sure the STUNT tool that has been 
> discussed here before would be a great help here.

Yes, exactly, but STUNT and STUN, which would benefit from behing
updated
with diagnostics matching the various BEHAVE documents.

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 10 Jul 2005 01:46:25 -0700 (PDT)

--- Francois Audet <audet@xxxxxxxxxx> wrote:

> (where XXX, YYYY are behave RFCs). 

[suresh] This is not adequate. I agree with David that there has to be a
consistent terminology that vendors could use when describing their NAT devices
 and their config parameters. It is not enough to say their box is BEHAVE RFC
compliant. The vendors will also refer other NAT RFCs and the terms they use
should be consistent across all RFCs.

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.  

cheers,
suresh

>                                    Soon. Not three years from now
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: David Barrett <[email-masked]>
Date: Sun, 10 Jul 2005 02:11:45 -0700 (PDT)

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