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

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

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

---

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

> terminology and characteristics that fully describe a NAT's behavior?

[suresh] Well, draft-ford-behave-gen-01.txt does just that - terminology and
general characteristics to characterize a NAT's behavior, with the proviso that
TCP/UDP specific drafts will reuse the terms from here to further characterize
TCP/UDP specific behaviors. As it stands, this is not a WG draft yet. 

> on terminology, and how to publicize a given NAT's behavior?
[suresh] Agreed. This was the intent behind the terminology defined in
draft-ford-behave-gen-01.txt.

> refresh period?  full cone?  restricted cone?  endpoint filtering?)
[suresh] You make an excellent point. Fully agree with your concern.

The ford-behave-gen draft refers "Address/Port Maps", "Bindings", "NAT
Sessions" , "Cone/Symmetric NAT behaviors", "Hairpin NAT" and "Multi-Level NAT"
to characterize a NAT behavior. 

"Hairpin NAT" and "Multi-level NAT" are new terms introduced for the first time
in this draft. It adds clarification to Cone/Symmteric NAT behaviors originally
defined in RFC 3489. The remaining terms are essentially reused from RFC 4008,
which is NAT MIB. NAT MIB refers to Binding timeout and NAT Session timeout.
So, do ford-behave-gen and sivakumar-behave-nat-tcp drafts. The intent was to
ensure vendors do not use inconsistent terms from across different RFCs.

> devices SHOULD report their behavior in a standardized fashion to enable 
[suresh] Right. Couldnt agree more.
 
> Does BEHAVE already do this?  Should it?
[suresh] I believe, we should. ford-behave-gen draft was done with this purpose
in mind. However, this is not a BEHAVE WG draft yet. 

cheers,
suresh

> -david
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>