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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jan 1999 17:44:22 +0100

I have read <draft-ietf-nat-snmp-alg-00.txt> and I think it describes
a nice experiment. However, my conclusions are that one should *not*
do IP address translation within SNMP. The reasons for my conclusions
are all in the document:

(a) Simple translations of the SNMP IpAddress data type causes
    inconsistencies since there are many places where IpAdresses
    are stored in other formats (see for example the TAddress TC
    defined in RFC 1903 and its usage in various IETF MIBs).

(b) Translations of IpAddress values in instance identifiers can break
    lexicographic ordering, which is a fundamental property of SNMP.

(c) Translations don't work with secure versions of SNMP without
    having to expose lots of keys to the translation box. This breaks
    the idea of having localized keys in SNMPv3 in the first place.

(d) It is questionable whether a management system can be useful if
    the real structure of the network is made not accessible by doing
    address translations in the management protocol.

(e) There are message size problems due to address translations.
    Translated messages can be larger than untranslated messages.
    This can cause SNMP transactions to fail when the translated
    message exceeds the max. message size, even though the real
    agent is aware of and honours this limit.

I think a better workable solution is to use SNMP proxies and to use
SNMP contexts (or community strings in SNMPv1/SNMPv2c) to let the
manager address the right destination. This will solve all the
problems mentioned above. Sure, it requires that the manager is aware
of the NAT situation, which I consider a feature.

I also found some editorial nits:

1) The draft says:

     The actual encoding of data in SNMP packets is done using BER -
     basic encoding rules, which provide the transfer syntax.  It uses
     part of the ASN.1 to define the abstract syntax of the messages.
     These standards are defined in ISO 8824-1, and ISO 8825-1.

   I suggest to change the order to:

     SNMP uses ASN.1 to define the abstract syntax of the
     messages. The actual encoding of the messages is done using the
     basic encoding rules (BER), which provide the transfer
     syntax. These standards are defined in ISO 8824-1, and ISO
     8825-1.

2) Some OIDs are written with a leading dot. I suggest to remote the
   leading dot since there is no such notation in ASN.1.

3) I don't understand the "one source of management applications"
   argument in section 6.1.

4) RFC 1441-1452 have been obsoleted by newer RFCs.

7) RFC 2261-2265 have been obsoleted by newer RFCs.

5) SNMPv2c is defined in RFC 1901-1908 and not in RFC 1902-1908.

6) I actually think that section 7 can be completely removed. This
   would also address me previous comments. If you keep section 7,
   please follow the text in <draft-ietf-snmpv3-intro-02.txt>.

7) Using `RFC XXXX or its successor' in the references is risky.

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