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

From: Scott Bradner <[email-masked]>
Date: Thu, 20 Sep 2001 13:11:45 -0400 (EDT)

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
[email-masked]
http://www1.ietf.org/mailman/listinfo/nat

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 24 Sep 2001 07:27:34 -0700 (PDT)

Scott,

Thank you for the comments. I will respond to the broad themes you raised. 
As for specific comments, I will respond to you in a separate e-mail.

History:

   09/98 - The NAT interface Framework draft had been around since 
           09/98. It had since evolved based on comments received 
           from several people (including Kjeld, Yakov for example)
           mostly through private e-mails and corridor conversations. 
   02/01 - Had several e-mail exchanges with the NAT-MIB draft authors
           who were using NAT interface framework draft as the basis for 
           their draft. The NAt draft was presented at MIDCOM BOF. 
           Several people suggested that I mention MIDCOM in the draft -
           so it is not a conflicting with MIDCOM, but rather complementary.
   04/01 - A new rev of the draft released including reference for MIDCOM.
   05/02/01 - The NAT draft completed WG last call and submitted to IESG. 
   06/02 - IESG sent me a note saying that MIDCOM WG should look at the
           draft for consistency with MIDCOM. 
   07/30 - No comments from MIDCOM list. Melinda sent you her referal.
   09/20 - IESG comments on the draft.

Editorial/Wording issues: 
   I apologize for having to put you through the ordeal. That was not 
   intentional. Hope you understand. I appreciate your feedback. I will
   fold in your comments and comb through the material meticulously one 
   more time as best as I can to fix these issues.

Relevance to the WG and interest from WG:

   Matt and I can certainly poll the WG to see if they believe the draft
   content is relevant to the WG and if there is any interest pursuing 
   the draft in the WG. If not this WG, I dont know what other WG would 
   be a more appropriate forum to review NAT interface stuff. When someone
   raised this issue, I recall polling the folks for interest level in 
   one of the IETF meetings. There were some nods that it is useful and 
   should be continued. There was no dissent that I can recall. Lastly, 
   the fact that the MIB draft was able to use this draft as the basis 
   for MIB definition, in my mind, is a direct proof of its relevance and
   usefulness.

Reference to MIDCOM, basis for MIDCOM:

   The NAT interface draft, along with Kuthan-firewall-traversal draft
   was indeed used as the basis for the MIDCOM Architecture and framework
   draft. The fact that the core architecture diagram (figure 1) in the
   MIDCOM framework draft is derived directly from the NAT interface
   draft figure-1 just goes to show how relevant the draft is. Several of
   the cocepts discussed (ALG interface, Callback notifications, API for
   BIND and session query, set and free) were borrowed into the MIDCOM
   draft discussion.

I hope to work with you in resolving the issues. Thank you.

Regards,
Suresh

> > 2.1. MiddleBox and Middlebox services

Where is this section from? Is this MIDCOM draft you are refering to?

> "application intelligence".
A firewall cannot permit FTP sessions wihout application intelligence.

> Not by the current definition, IMO.
OK. I will fix this.
 
> Is the defn of a midcom agent consistent with the terminology the
I believe so. Here is what I have from MIDCOM draft.
 
> What is a "realm type"? Document doesn't seem to say.

OK, I will add refernce to RFC 2663.

> "the BIND". Is there one BIND on a NAT box? Or many? you never define
Refer RFC 2663.

> these inputs from somewhere? 

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 24 Sep 2001 07:28:30 -0700 (PDT)

Scott,

History:

Regards,
Suresh

> these inputs from somewhere? 

=====