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

From: Dan Raz <[email-masked]>
Date: Thu, 11 Mar 1999 17:49:13 -0500

Dear Dr. Jürgen Schönwälder,

Thanks for your comprehensive review of the draft. Though
we found several parts of your comments useful and relevant
we do not agree with your overall recommendation that a tool like
SNMP-ALG is not needed.

In reality, SNMP-ALG was designed to address a real existing
need for which no alternative approaches are available. In principle
every NAT ALG can be replaced by a NAT aware application.
That is, if the application uses IP addresses, and it has access
to the translation tables, it can do the translation.
However, making the binary version of an application aware of the
need for translation, and communicating the translating table to it is
at best a difficult task
In particular, there are thousands of network management systems
running numerous applications that are deployed today and  are not
(and most likely will not be in the near future) aware of NAT.
This is the main reason why NAT-SNMP-ALG is needed and
is intended to address.

Regarding the more concrete comments:

(a)  As mentioned in the draft in section 4.3, different
     (i.e. non-standard) encoding of IP addresses can be
     handled by specific OID translation.

(b)  True, lexicographic ordering, may break (as mentioned in
     the draft).  However, in the practical setting (see above)
     most NM applications do not make use this ordering.
     When an entire table is read using GetNext, the ordering
     plays a secondary role.

(c)  Again, this is a general NAT ALG problem, and it is not unique
     to SNMP.  We did touch upon this problem in section 6.1 of the
     draft.

(d)  The fact is, that management systems need to be used in many
     cases in network where NAT is used.  In fact, the draft presents
     a feasible solution which was tested in practice, and shows that
     management system can be indeed useful in such scenarios.

(e)  As described in section 5.0 of the draft, translation
     (only the OID non-standard one) may change the size of packets.
     We agree that theoretically the maximum packets size may be
     violated, however, in practice, in the practical scenarios we
     checked, packets sizes are far from the limit, and packets
     contain a small number (i.e. mostly one) of IP addresses,
     so that the size different, if any, will be small.

(f)  In section 6.1 we mentioned ""one source of management
     applications". This was referring to the fact that in
     many cases, there is only one management application that
     is talking to a specific network element.  This makes the
     keys distribution problem much easier.

(g)  Regarding the use of `RFC XXXX or its successor' in the references.

     It seems like a very common practice in internet drafts, but we do
     agree it is risky.

(h)  About section 7.  We  do agree that some clarifications regarding
     SNMP versions, are important here.

Thanks for correcting our references, and for the editorial suggestions.
We will use them to prepare the next version of the draft.

Danny Raz and Binay Sugla
-- 

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Mar 1999 13:05:00 +0100

>>>>> Dan Raz writes:

Dan> In reality, SNMP-ALG was designed to address a real existing need
Dan> for which no alternative approaches are available. In principle
Dan> every NAT ALG can be replaced by a NAT aware application.  That
Dan> is, if the application uses IP addresses, and it has access to
Dan> the translation tables, it can do the translation.  However,
Dan> making the binary version of an application aware of the need for
Dan> translation, and communicating the translating table to it is at
Dan> best a difficult task In particular, there are thousands of
Dan> network management systems running numerous applications that are
Dan> deployed today and are not (and most likely will not be in the
Dan> near future) aware of NAT.  This is the main reason why
Dan> NAT-SNMP-ALG is needed and is intended to address.

You can use SNMP proxies if you need to move SNMP traffic across a NAT
box. SNMP proxies do not require any changes to existing management
systems. Sure, an SNMP proxy is not absolutely transparent since the
manager has to address the target device through the proxy.  But SNMP
proxies have been around for years, SNMP proxy technology is already
on the standards track, and SNMP proxies do not break basic SNMP
rules.

Dan> (a) As mentioned in the draft in section 4.3, different
Dan> (i.e. non-standard) encoding of IP addresses can be handled by
Dan> specific OID translation.

Are you saying that for every new agent which shows up behind a NAT
box and which has an IP address in a not-yet-known place, I need to go
to the NAT-SNMP-ALG and configure it (or even recode it) to make
things work?

Dan> (b) True, lexicographic ordering, may break (as mentioned in the
Dan> draft).  However, in the practical setting (see above) most NM
Dan> applications do not make use this ordering.  When an entire table
Dan> is read using GetNext, the ordering plays a secondary role.

I have *serious* problems here. Lexicographic ordering is a
fundamental property of SNMPv1 (Standard) and SNMPv2 (Draft). Just
saying that those applications you are familiar with did not screw up
by breaking lexicographic ordering is IMHO not an acceptable argument.
(BTW, I have been in several IETF WGs where people optimized table
indexing schemes so that efficient retrieval of parts of tables is
possible.)

Dan> (d) The fact is, that management systems need to be used in many
Dan> cases in network where NAT is used.  In fact, the draft presents
Dan> a feasible solution which was tested in practice, and shows that
Dan> management system can be indeed useful in such scenarios.

Interoperability was always one of fundamental concerns within the
IETF. I claim that the NAT-SNMP-ALG causes interoperability problems.
What is feasible in your environment may be completely unworkable
somewhere else.

Dan> (e) As described in section 5.0 of the draft, translation (only
Dan> the OID non-standard one) may change the size of packets.  We
Dan> agree that theoretically the maximum packets size may be
Dan> violated, however, in practice, in the practical scenarios we
Dan> checked, packets sizes are far from the limit, and packets
Dan> contain a small number (i.e. mostly one) of IP addresses, so that
Dan> the size different, if any, will be small.

This is the second point where I have *serious* problems. SNMPv2c and
SNMPv3 has getbulk and I know agents from well known SNMP toolkit
vendors that do repetitions until they reach the max message size (as
defined in the relevant standards track specs). The fact that you did
not reach packets size limits in your environment is IMHO not a good
reason to argue that there is no such problem.

Once again, I appreciate the work you have done. However, we must draw
the right conclusions.
							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.