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

From: "Francois Audet" <[email-masked]>
Date: Fri, 8 Jul 2005 19:17:34 -0700 (PDT)

Right,

Both the TCP and UDP drafts (and potentially others) will define
terminology and Requirements.

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".

We haven't received any submission on this last topic so far, but it
would
be quite appreciated.

It would help validate the other drafts in the real world.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> David Barrett
> Sent: Friday, July 08, 2005 18:35
> To: 'Behave'
> Subject: [Ietf-behave] Determining the precise behavior of a 
> given NAT model
> 
> 
> What is and will be the process for determining the specific 
> behavior of 
> a given NAT?  Is there, or will there be, a 
> formally-standardized set of 
> terminology and characteristics that fully describe a NAT's behavior?
> 
> 
> A major goal of the BEHAVE draft is reduce the diversity of NATs 
> deployed to a more manageable set.  However, there will still be a 
> diversity, even if every NAT device is fully compliant.  Thus if we 
> fast-forward to a post-BEHAVE world, what will the process be to 
> determine what kind of NAT I have?  Does BEHAVE make any 
> recommendations 
> on terminology, and how to publicize a given NAT's behavior?
> 
> To give a specific example, I'm testing with a Zyxel NAT, and 
> it appears 
> to have a very small NAT-refresh window with address-restricted 
> filtering.  However, I can't find any clear description in the Zyxel 
> product literature detailing whether this is true or not, nor is it 
> clear what specifically I should be looking for (mapping timeouts? 
> refresh period?  full cone?  restricted cone?  endpoint filtering?)
> 
> What would be helpful is a clear set of variables that completely 
> describe the BEHAVE-regulated NAT criteria, with well-defined 
> possible 
> answers.  In this way a NAT can say "100% BEHAVE Compliant!" and then 
> completely describe its behavior (Endpoint filtering: address 
> restricted.  NAT mapping lease duration: 20s.  ...etc...).  It would 
> seem to fit the charter of the BEHAVE draft to recommend that 
> compliant 
> devices SHOULD report their behavior in a standardized 
> fashion to enable 
> reliable comparisions.
> 
> Take, for example, the endpoint filtering debate.  If we 
> don't require 
> that devices implement both in a configurable fashion, and if 
> we don't 
> require that devices clearly say which they are, how can a customer 
> reasonably be expected to make an intelligent choice about 
> which to buy?
> 
> Does BEHAVE already do this?  Should it?
> 
> -david
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: David Barrett <[email-masked]>
Date: Fri, 8 Jul 2005 19:35:28 -0700 (PDT)

Francois Audet wrote:
Both the TCP and UDP drafts (and potentially others) will define
terminology and Requirements.
Good.  But is there any requirement or recommendation that NAT vendors 
document their NAT's behaviors using this terminology?

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?

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.

-david