[NAT] IESG review of draft-ietf-nat-interface-framework-03.txt

The IESG has discussed draft-ietf-nat-interface-framework-03.txt and
has the following comments

Scott & Allison

------
The IESG has some concerns with the document
draft-ietf-nat-interface-framework-03.txt.

1) The document has numerous editorial and wording issues that make it
   difficult to give the document a proper technical review. Moreover,
   it is believed that many of these issues should be apparent to
   others who attempt to give the document a serious technical
   review. As the document is currently written, it is not believed to
   be ready for publication as an RFC. Consequently:

2) It is not job of the IESG to provide detailed technical and
   editorial corrections on documents to the degree needed on this
   document. A sample of such commentary on the first few pages of the
   ID is appended. The remainder of the document has similar issues,
   but the details are not provided.

3) A brief perusal of the mailing list archives suggests that WG
   support for this document is limited; i.e., the document appears to
   have no opposition, rather than significant support. If the WG
   believes that this document is important, it should take steps to 
   demonstrate that support more explicitely.

4) If the WG believes that work on this document should continue, it
   should take steps to cleanup the document. Suggested steps in this
   direction would be to have WG members perform detailed reviews,
   feed comments back to the author, and then indicate satisfaction
   with the resultant revised document. It may also be useful to find
   an additional document editor willing to do some technical editing.

5) The document makes a lot of references to MIDCOM, implying that the
   document is of relevance to MIDCOM and will serve as a starting
   point for additional MIDCOM work (i.e., an API for accessing MIDCOM
   resources). If this document really is of use/interest to MIDCOM,
   that WG should perhaps pick up the work. If the MIDCOM WG does not
   agree, then much of the text implying this is of use to MIDCOM
   would seem to be inappropriate, and the scope of the document
   should be appropriately narrowed.

Specific document comments (not complete - intended as examples): 

   flavors of NAT that abound. Many internet applications use IP
s/use IP/use an IP/
   address as host identifier rather than just as a way to locate a
s/as host/as a host/
   host.  For this reason, routing transparency by NAT alone is not

It is not just applications, it is also transport protocols like UDP
and TCP.

Thus, saying "for this reason, ..." is misleading. One would not get
end-to-end transparancey just by fixing applications.

>    operating across realms.  Application specific ALGs are required
>    in conjunction with NAT to provide end-to-end transparency for
>    some applications.

ALGs do NOT provide end-to-end transparency. Perhaps I'm having
trouble with some of this text because the authors may have a
different idea of what end-to-end transparency means (e.g., does IPsec
work through an ALG)? Perhaps the document should define the term.

   specific. The API illustration assumes a trusted environment and
   does not address authentication, authorization or discovery of
   middlebox location. It is also important to note that the

Ommitting security issues seems a significant ommision in practice.

> 2.1. MiddleBox and Middlebox services
>
>    Middlebox is a network intermediate device implementing a
s/Middlebox/A middlebox/
>    middlebox service. Middlebox service is characterized as a
s/Middlebox/A middlebox/
   networking function requiring application intelligence for
   its operation. A middlebox service is also referred as
s/referred/referred to/
   Middlebox function throughout this document. Examples of
   middlebox functions include NAT, firewall, intrusion
   detection, load balancing, policy based tunneling and
   IPsec security Gateway enforcement. A middlebox may
   implement one or more of these functions. 

NAT is not a middlebox per the document's own definition. NAT does not
require "application intelligence". NAT does require ALGs when NAT
doesn't work, but an ALG is not a NAT.

I also wonder whether  folks would agree that firewalls need
"application intelligence".

   Clearly, NAT is a specific middlebox function and NAT device
   is a specific Middlebox device.

Not by the current definition, IMO.

   MIDCOM agents are entities performing ALG function, logically
   external to a middlebox. MIDCOM agents possess a combination of

Is the defn of a midcom agent consistent with the terminology the
midcom WG uses?

   The protocol used by MIDCOM agents to interface with the middlebox
   and its resources to influence its operation. This is a protocol

sentence doesn't parse.

   through 3.1.2 are independent of the service the devise supports.

s/devise/device/

>    agent may influence NAT operation. This section describes objects
>    within NAT, that could be externalized via Management Information
>    Base (MIB).

Is this intended to mean MIB in the standard IETF sense? If so, how
does this relate to the NAT-MIB document? Indeed, why isn't this
document just an API to get at the same objects as defined in the MIB?

>    Of the fields listed below to describe the service, items 3.1.1
>    through 3.1.2 are independent of the service the devise supports.

s/devise/device/

>   instances or there may be multiple NAT middleboxs associated
s/middleboxs/middelboxes/

3.1.1. Service IDentifier

   A service identifier uniquely identifies service instantiation
   within a middlebox. The external interface address may be
   one way to uniquely describe this Identifier.

Circular definition? (at least, I don't understand what this means).

>    Every NAT device will have a minimum of two routing
>    interfaces, one connecting to a private realm and one
>    connecting to external realm. An IPv4 NAT device will
>    have both its realm types set to IPv4.

What is a "realm type"? Document doesn't seem to say.

   Address map on a NAT device is constituted of one or more of
   static/ dynamic Address maps. Transport-ID mapping, on

s/Address/An address/? 

> 3.2. Address (and Transport-ID) BIND Descriptor
>
>    Hereafter, the term BIND will be used in place of BINDing, for ease
>    of use. BIND descriptor is specific to NAT service. These BINDs
>    can be static or dynamic. When external agents do not intervene,

This above is really unclear. What is a "BINDing" Why use the
terminology "BIND"?

> 3.2.1. Bind ID
>
>    A number (say, in the range of 1 through 0xFFFFFFFF) assigned
>    to BIND to uniquely identify the BIND on a NAT middlebox.

"the BIND". Is there one BIND on a NAT box? Or many? you never define
just what a BIND is.

> 3.2.2. Direction of Bind
>
>    A bind can be uni-directional or bi-directional, same as the 
>    orientation of address map based on which this BIND is formed.
>    As before, the direction is with reference to private realm.

This is confusing. When NAT is in place, it seems like there would be
one binding that shows the translations going in both directions (for
a particular connection/flow). Why would one have separate binding to
show what is going on in only one direction? And there is
unidirectional NAT?  What is that?

   the same concept to the tuple of Address and transport ID (such as

Why is Address capitalized?

> 3.2.4. Private and External addresses (and Transport-IDs)
>
>    These parameters specify the BINDing items in private and
>    external realms.

The use of terminology is really hard to follow. I'm having a hard
time understanding what is meant by "specify the BINDing items".
Do you really mean to say something like "... specify the items that
define a binding ..." Or something else? And why "parameters"? Are
these inputs from somewhere? 

_______________________________________________
nat mailing list
nat@ietf.org
http://www1.ietf.org/mailman/listinfo/nat