Subject: (NAT) comments on draft-ietf-nat-snmp-alg-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Oct 1999 16:50:31 +0200

I have read the new revision of the SNMP ALG document. The memo did
improve quite a bit. However, I still have comments/concerns with
<draft-ietf-nat-snmp-alg-01.txt>. Here are the details:

 (1) I think that section 2 needs some additional work. I would like to
     see a clear problem/requirements statement here and I would like
     to see convincing reasons here why other approaches do not match
     the requirements. I think it is important to be very clear on the
     applicability and implications of SNMP ALG up-front instead of
     distributing this information throughout the document (mainly
     section 2, 5.3-5.5 and 7).
 
 (2) I have problems with the following paragraph in section 2:
 
     : The SNMP ALG solution suggested fits predominantly the SNMP V1
     : based applications, not using proprietary MIBs.  The solution, as
     : presented, does not require knowledge of the MIBs.  However,
     : extension to this approach may be adapted, as necessary to fit
     : specific situations.
 
     I am confused what "not using proprietary MIBs" means. If I
     understand the draft correctly, then you have different levels of
     SNMP ALGs. Those SNMP ALGs that only translate the BER tagged
     IpAddress in SNMP messages and PDUs break MIB semantics even in
     standards MIBs (e.g. the TCP connection table). Those SNMP ALGs
     that also translate IP addresses encoded in other data types and
     instance identifier will provide better transparency, but they
     need to be MIB aware, break lexicographic ordering and may have
     message size problems.
 
     I think it is important to be precise about the various levels of
     SNMP ALGs described in the memo (I suggest to give them names) and
     to say up-front what these various levels of SNMP ALGs can do and
     what the restrictions are. Some ideas:
 
     "Basic SNMP ALG" is an SNMP ALG implementation which is only
     capable to translate IpAddress values in a BER encoded byte
     stream.
 
     "Advanced SNMP ALG" is an SNMP ALG implementation which is
     generally MIB aware and is capable to handle and replace IpAddress
     values endecoded in instance identifiers. Note that an advanced
     SNMP ALG can be implemented to read and interpret MIB definitions
     loaded at runtime.
 
     "Transparent SNMP ALG" is an SNMP ALG implementation which is MIB
     aware and which has additional knowledge needed to replace IP
     addresses embedded in all other SNMP data types (e.g. TAddress)
     they are used in a set of MIBs. In other words, an implementation
     can only claim to be a transparent SNMP ALG for a given set of MIB
     modules.
 
     Once these names are defined, you can be more precise in your
     statements. (It is currently not always clear whether a particular
     statement applies to a basic/advanced/transparent SNMP ALG.)
 
 (3) The first paragraph on page 4 says that that SNMP packets "are
     typically UDP packets that contain PDUs - Protocol Data Units".
     Here are some other wordings for the first paragraph in section 3:
 
     + In general we adapt the terminology used in [SH 99].  Our main
     + concern is packets used by the SNMP protocol.  These are
     + typically UDP packets that contain SNMP messages. SNMP messages
     + contain PDUs (Protocol Data Units) which defines the parameters
     + for SNMP protocol operations. The notion of flow is less relevant
     + in this case, and hence we will focus on the information
     + contained in a single packet.
 
     + SNMP version 1 is defined in RFC 1157. Other RFCs (1155, 1213,
     + 1215) define the Structure of the Management Information (SMI) 
     + and the core Management Information Base (MIB). For simplicity,
     + unless otherwise mentioned, we refer to SNMP version 1 as
     + SNMP. See RFC 2570 for an introduction to related SNMP standards.
 
 (4) I have problems reading the second sentence in the second
     paragraph in section 4. Here is a proposal for some new wordings:
 
     + Managing devices execute management applications that typically
     + use SNMP to exchanges IP address related information.
 
 (5) In section 5.1, you wrote that an "OID gives a unique
     identification to each variable both in time and space". I am not
     sure why the phrase "both in time and space" is needed since I am
     not sure how I should interpret this phrase. (Note that the SNMPv3
     architecture actually clarifies the SNMP naming systems and talks
     about scoped names that are unique within a management domain.)
     There is also an important distinction between OIDs that refer to
     object type definitions and OIDs that refer to concrete instances
     of an object type. I suggest to simply remove the phrase "both in
     time and space".
 
 (6) Third sentence in section 5.1: I suggest to replace "Each such an
     element" with "Each variable".
 
 (7) In the figure on page 7, replace "PDU" (just below the UDP Header
     box) with "SNMP Message".
 
 (8) In the text below the figure on page 7, please replace:
 
     The next four bytes 30 82 00 3E are the beginning of the PDU: 30
     is SEQUENCE OF, and 82 00 3E is the length of the payload in
     bytes (62).
 
     with the following sentence:
 
     The next four bytes 30 82 00 3E are the beginning of the SNMP
     Message: 30 is SEQUENCE, and 82 00 3E is the length of the payload
     in bytes (62).
 
     (Note that an SNMP message is a SEQUENCE and not a SEQUENCE OF.)
 
 (9) Still in the text below the figure on page 7, please replace:
 
     Now come the variables (i.e. the real data): SEQUENCE of length 31
     (30 82 00 1F).
 
     with the following sentence:
 
     Now come the variables (i.e. the real data): SEQUENCE OF of length
     31 (30 82 00 1F).

(10) In section 5.3, you describe that MIB specific translations may
     be necessary. I generally agree with this statement, but I have
     serious concerns with the title "proprietary MIB translation"
     and the phrase "proprietary or private MIB". Several standards
     track MIBs encoded IPv4 addresses in other data types. (See alone
     the TAddress textual convention and SnmpUDPAddress.)

(11) I suggest to merge the text in section 5.2-5.5 into the section
     which introduces the terms Basic/Advanced/Transparent SNMP ALG.

(12) The last sentence in section 5.5 is ambiguous. You talk about
     "outgoing" packets. Since an SNMP ALG sends packets to the SNMP
     manager and to the SNMP agents, this phrase is ambiguous and
     can be mis-understood.

(13) The following text is copied from section 7.0:

     : One alternative solution to SNMP ALG may be to use SNMP proxies
     : and to use SNMP contexts (or community strings in SNMPv1/SNMPv2c)
     : to let the manager address the right destination.  This solution,
     : which is structurally preferable, requires that the management
     : station will be aware of the NAT situation, which is a feature
     : that cannot be found in many existing management systems.  It
     : also involves reconfiguration of both the network elements and
     : the management station.
    
     I think it is sufficient for the management station to be aware of
     the proxy situation, not necessarily the NAT situation.

     I do not understand why the introduction of a proxy requires to
     reconfigure the network elements. Please explain or remove this
     text.

(14) In section 8, you give references to (newer) SNMP versions. I
     suggest to refer to RFC 2570 rather than the coexistance ID.
     The memo also has the following statement:

     : This document covers SNMPv1.  However, since the basic encoding
     : of the PDU, including the use of the IP address type, in SNMPv2
     : is very much similar to SNMPv1, the principles of SNMP ALG as
     : described in Sections 4 and 5 are valid for SNMPv2c.  The use of
     : SNMP ALG for SNMPv3 is not covered by this document.

     I personally would like to see a statement for SNMPv3 as well
     since SNMPv3 is the SNMP version which is likely to replace
     SNMPv1 as far as the IETF standards process is concerned. And
     the statement for SNMPv3 is most likely that an SNMP ALG breaks
     all security services unless the SNMP ALG has access to all the
     localized keys. (Perhaps this should be said upfront or in a
     special security considerations section.)

(15) The references still need some work:

     - There is a newer version for reference [FE 98] which also has
       different authors/editors: draft-ietf-nat-traditional-02.txt

     - Reference [SH 99] has been published as RFC 2663.

     - The SNMPv1 protocol is defined in RFC 1157 (STD 15) and not in
       RFC 1067. The MIB-II is defined in RFC 1213 (STD 17) and not in
       RFC 1066. I suggest to remove the reference for RFC 1066 and
       RFC 1067.

     - SNMPv3 is defined in RFC 2571-2575 which replace RFC 2261-2265.

     - Note that RFC 1155 is also STD 16. (The RFC editor loves STD
       numbers in addition to RFC numbers.)

     - RFC 1213 was published in March (you have a typo there).

     - The ASN.1 references are not necessarily compatible with the
       ASN.1 version used by the SNMP protocol.

     - The author names in reference [FLRW 99] need to be fixed by
       inserting "Levi, S. A." just before Routhier. (There is also
       a newer version of this ID.) Note that my suggestion to refer
       to RFC 2570 instead will make this reference obsolete.

Thats it.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Dan Raz <[email-masked]>
Date: Tue, 19 Oct 1999 17:53:04 -0400

Juergen, 

We had just submitted a new version that addresses all your points.

>      section 2, 5.3-5.5 and 7).

I agree. This is the reason we added this section.  It is, however,
fairly difficult to explain all the details of the limitations without
explaining what SNMP ALG does (and how).  We added the classification
according to your suggestion, and pointed out the main limitations.
However, it seems better, methodically, to leave the detailed 
explanations to Section 7.

>      statement applies to a basic/advanced/transparent SNMP ALG.)

You are right.  The main distinction is between translation of IpAddress
types, and general types.  We did use "not using proprietary MIBs" 
in an inaccurate way.  This is fixed.

I do not think that "Transparent SNMP ALG" is yet another 
level of implementation.  We added explanations similar to the one you 
provided here in Section 7.

>  (3) -- (10)

O.K.

>      which introduces the terms Basic/Advanced/Transparent SNMP ALG.

See my remark to (1).
 
>      manager and to the SNMP agents, this phrase is ambiguous and

Definitions of outgoing/incoming added to Section 3 (terminology).

>      reconfigure the network elements. Please explain or remove this

I changed the text and added explanations.

>      special security considerations section.)

I added reference to RFC 2570, but the ID has a more detailed
description of the different versions.  
We do state in Section 7.1 that SNMP ALG should have
access to all the keys in the translated realm.  
We also explain why in the scope
of the document this may be a reasonable assumption.

>   .............
> .............

Fixed.  I do think that the ASN.1 reference are O.K. although some SNMP
RFC's refer to an older (1987) version of the IOS.

> Thats it.

Thanks, we really appreciate your input.

-- 

Danny Raz                       Tel: 732-949-6712
Room 4G-637                     Fax: 732-949-0399
Bell-Labs                       email: [email-masked]
101 Crawfords Corner Road       
Holmdel, NJ 07733 - 3030
WWW: http://www.cs.bell-labs.com/~raz
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.