Transport Working Group                            D. Raz
  INTERNET-DRAFT                            Bell-Labs, Lucent
  Category: Informational                           B. Sugla
  Expire in six months                      Bell-Labs, Lucent
                                                  December  1998

     An SNMP Application Level Gateway for Payload Address Translation

  Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet- Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months.  Internet-Drafts may be updated, replaced, or obsoleted
     by other documents at any time.  It is not appropriate to use
     Internet-Drafts as reference material or to cite them other than
     as a "working draft" or "work in progress".

     To learn the current status of any Internet-Draft, please check
     the 1id-abstracts.txt listing contained in the Internet-Drafts
     Shadow Directories on (US East Coast), (Europe), (US West Coast), or (Pacific Rim).


     The SNMP Application Level Gateway for Payload Address
     Translation described in this document is a specific case of an
     Application Level Gateway (ALG), as described in [SH 98] and [SE
     98].  It includes detailed description of the need and
     implementations of such a gateway for SNMP (Simple Network
     Management Protocol).


     The SNMP Application Level Gateway for Payload Address
     Translation (SALG-PAT) is a feature by which IP addresses in the
     payload of SNMP packets are statically mapped from one group to
     another, transparent to management application.  This is a
     specific case of Application Level Gateway, ALG, as described in
     [SH 98] and [SE 98].  When combined with basic NAT, this document
     describes a mechanism by which a management device can manage
     multiple networks that use conflicting IP addresses.

Raz & Sugla                                                     [Page 1]

Internet Draft       SNMP Application Level Gateway        December 1998

  1. Introduction

     The need for IP address translation arises when a network's
     internal IP addresses cannot be used outside the network either
     for security reasons or because they are invalid for use outside
     the network.  Topology outside a local domain can change in many
     ways.  Customers may change providers, company backbones may be
     reorganized, or providers may merge or split.  Address
     translation allows hosts in such private networks to
     transparently access an external network and vice versa.

     In many of these cases, there is a need to manage the local
     domain from a manager site outside the domain.  However, managing
     such networks is a big problem.  Most available management
     devices use SNMP (Simple Network Management Protocol) to retrieve
     address information from the network elements.  In this case a
     router may be queried by the management software about the
     addresses of its neighbor elements.  This information is then
     sent by the router back to the management device as part of the
     payload of an SNMP packet.  In order to retain consistency in the
     view as seen by the management device we need to be able to also
     locate and translate IP address related information in the
     payload of such packets.

     The SNMP Application Level Gateway for Payload Address
     Translation, or SALG-PAT, is a technique in which the payload of
     SNMP packets (PDUs) is scanned and all IP address related
     information is translated if needed.  This is a particular
     example of Application Level Gateways (ALGs) as described in [SH
     98] and [SE 98]:  "ALG are application specific translation
     agents that allow hosts from one routing realm to connect to
     hosts in a different realm.  The ALGs may optionally utilize
     address/port assignments by NAT and perform translations of
     packets pertaining to the application."

     In this context SALG-PAT can be an additional component in any
     NAT implementation, or be a separate entity, that may reside in
     the same gateway or even on a separate node.  Note that we deal
     with management application, and hence all devices in the network
     are assumed to have a fixed IP address.  Thus, SALG-PAT should
     only be combined with basic NAT that uses static mapping.

  2. Terminology and concepts used

     In general we adapt the terminology used in [SH 98].  Our main

Raz & Sugla                                                     [Page 2]

Internet Draft       SNMP Application Level Gateway        December 1998

     concern are packets used by the SNMP protocol.  These are
     typically UDP packets that contain PDUs - Protocol Data Units.
     The notion of flow is less relevant in this case, and hence we
     will focus on the information contained in a single packet.  The
     main definition of SNMP is from RFC 1157.  Other RFCs (1155,
     1213, 1215) define the structure of the managed information (SMI)
     and the management information base (MIB).  There are many
     versions of SNMP.  For simplicity, unless otherwise mentioned, we
     refer to SNMP version 1 as SNMP.

     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.

     As mentioned before, SALG-PAT is a specific example of the
     Application Level gateway (ALG) described in [SH 98] and [SE 98].
     Application Level Gateways (ALGs) are application specific
     translation agents that allow hosts from one routing realm to
     connect to hosts in a different realm.  The ALGs may optionally
     utilize address/port assignments by NAT and perform translation
     of packets pertaining to the application.

     We also refer in this document to IPv4, and thus we refer to IPv4
     addresses as just IP addresses.  We also use some terminology
     from the IP security domain.  In particular we will refer to IP
     over IP as defined in RFC 2003, as tunneling.

  3. Overview of the SNMP application level gateway

     Using basic address translation allows local hosts on a
     private network to transparently access the external global
     network and enables access to selective local hosts from the
     outside.  This solution is becoming widely popular as the range
     of IPv4 addresses is limited.  In particular it is not unlikely
     to have several private networks that are using the same private
     IP address space within the same organization.

     However, managing such a network presents unique problems and
     challenges.  Managing devices typically use the SNMP simple
     network management protocol, which is an application that
     exchanges IP address related information.  Thus, in order for the
     SNMP application to work properly across NAT, Application Level
     Gateways, or ALGs, must be used to perform translation on SNMP
     packets.  This translation of the payload of SNMP packets is
     called an SNMP Application Level Gateway for Payload Address
     Translation - or just SALG-PAT.

Raz & Sugla                                                     [Page 3]

Internet Draft       SNMP Application Level Gateway        December 1998

     A typical scenario where SALG-PAT is deployed as part of NAT is
     presented in figure 1.  A manager device is managing a remote
     stub, with translated IP addresses.

          \ | /                 .
     +---------------+  WAN     .
     |Regional Router|-------------------|Stub Router w/NAT and
     +---------------+          .
             |                  .                   |
             |                  .                   |  LAN
        +----------+            .            ---------------
        |Manager   |      Stub border           Managed network
                    Figure 1: NAT+SALG-PAT configuration

     A similar scenario occurs when several subnetworks with private
     (and possibly conflicting) IP addresses are to be managed by the
     same management station.  This scenario is presented in Figure 2.

                                  \ |  /
                   +-------------------+     +-----------------+
                   |    Access   Router|-----|Management device|
                   |w/ NAT and SALG-PAT|     +-----------------+
                     T1  |           | T1
                         |           |
     Stub A .............|....   ....|............ Stub B
                         |           |
                         |           |
               +------------+      +------------+
               |Stub Router |      |Stub Router |
               +------------+      +------------+
                 |                         |
                 |  LAN               LAN  |
             -------------             -------------
          192.10.x.y   |                 |  192.10.x.y
                     /____\           /____\

         Figure 2: Using SALG-PAT+NAT to manage two private networks

     Since the devices in the managed network are monitored by the
     manager device they must obtain a fixed IP address. Therefore,

Raz & Sugla                                                     [Page 4]

Internet Draft       SNMP Application Level Gateway        December 1998

     the NAT used in this case must be a basic NAT with a static one
     to one mapping.

     A management payload translator is required to scan all the
     payload of SNMP packets, to detect IP address related data, and
     to translate this data if needed.  This is a much more
     computationally involved process than the basic NAT, however they
     both use the same translation tables.  In many cases the router
     may be unable to handle SALG-PAT and retain acceptable
     performance.  In these cases it may be better to locate the
     SALG-PAT outside the router.

     3.1 SALG-PAT on a separate machine

     As described before, in some cases it may be beneficial to locate
     the SALG-PAT functionality in a separate node in the network.
     This can be done using tunneling.  The use of SALG-PAT as
     described in this section can be generalized for any ALG, but
     different restrictions and considerations are required, which are
     out of the scope of this document.

                                       |  SALG-PAT   |
                           \ |  /          |
                         +---------------+ |   +-----------------+
                         |Access   Router|-----|Management device|
                         |w/ NAT(and SA) |     +-----------------+
                       T1  |           | T1
                           |           |
       Stub A .............|....   ....|............ Stub B
                           |           |
                 +------------+      +------------+
                 |Stub Router |      |Stub Router |
                 +------------+      +------------+
                   |                         |
                   |  LAN               LAN  |
           -------------             -------------
        192.10.x.y   |                 |  192.10.x.y
                   /____\           /____\

      Figure 3: Using external SALG-PAT to manage two private networks

     The idea here is to send the packets that belong to a specific
     application (SNMP PDUs in our case) to the appropriate external

Raz & Sugla                                                     [Page 5]

Internet Draft       SNMP Application Level Gateway        December 1998

     ALG, using tunneling.  These packets arrive at the remote ALG,
     the appropriate filter is applied to them, and then they are
     either injected to the network, or tunneled back to the access
     router, and from there to the network.

  4.0  Parsing and translating data in SNMP packets

     SNMP packets are built using the ASN.1/BER encoding.  We will not
     cover the full details of this encoding in this document.  These
     details can be found in the International Standards ISO-8824 and
     ISO-8825.  A good description of ASN.1/BER can be found in the
     book Managing Internetworks with SNMP, by M.  A.  Miller [Mi 97],
     or in Appendix A of the book Understanding SNMP MIBs, by D.
     Perkins, and E.  McGinnis [PM 97].

  4.1. General description of the encoding of data in
       SNMP PDU's (ASN.1 and BER)

     In general, each variable that is referred to in an SNMP packet
     has a unique OID (Object Identifier) which is a set of numbers
     separated by a dot (for example:  This OID gives
     unique identification to each variable both in time and space.
     Each such an element also has a type (this is not very accurate
     but good enough for this level of description).  One possible
     type is the IP address type.  The type of each piece of data, and
     its OID are part of the ASN.1/BER encoding.  When a value of a
     variable is needed by a manager it sends a get-request PDU with
     the OID of that variable, and a null value.  The managed element
     then responds by sending a get-response PDU that has in it the
     same OID, the type of the variable, and the current value.  Here
     is an example of real data in an SNMP get-response PDU

Raz & Sugla                                                     [Page 6]

Internet Draft       SNMP Application Level Gateway        December 1998

     |       IP Header                         |     45 00 00 5E
     |                                         |     47 40 00 00
     |                                         |     3F 11 39 00
     |                                         |     87 B4 8C CA
     |                                         |     87 B4 8C 16
     |       UDP Header                        |     00 A1 05 F5
     |                                         |     00 4A D3 65
     |       PDU                               |     30 82 00 3E
     |  version                     |          |     02 01 00 04
     |  Community = public                     |     06 70 75 62
     |                              |          |     6C 69 63 A2
     |   PDU Type                   |          |     82 00 2F 02
     | Request ID                              |     04 6C F2 0C
     |           |   Error Status              |     5C 02 01 00
     |  Error Index                 | SEQUENCE |     02 01 00 30
     |  of length 31                | SEQUENCE |     82 00 1F 30
     |  of length 27                | OID      |     82 00 1B 06
     | length=19 |                             |     13 2B 06 01
     |                                         |     02 01 07 05
     |                                         |     01 01 81 40
     |                                         |     81 34 81 0C
     |                                         |     81 4A 84 08
     |  IP Type            | 135    | 180      |     40 04 87 B4
     |  140      | 202     +-------------------+     8C CA

     The first 20 bytes are the IP header.  The next 8 bytes are the
     UDP header, with the last two byte in it the UDP checksum (D3 65).
     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).  Next come the Version (02 01 00) and the Community
     (04 06 ..  63 = public).  The next part is the PDU, first item is
     the PDU type (A2 82 00 2F = GetResponse), the request ID (02 04
     6C F2 0C 5C), the Error Status (02 01 00 = No Error), and the
     Error Index (02 01 00).  Now come the variables (i.e.  the real
     data):  SEQUENCE of length 31 (30 82 00 1F).  The first element
     is a SEQUENCE of length 27 (30 82 00 1B).  In it, the first
     object is an OID of length 19 (06 13), then comes the OID:
     .  The last 6 octets 40
     04 87 B4 8C CA represent an IP address:  40 is the type IP
     address, 04 is the length, and the next four octets are the IP

Raz & Sugla                                                     [Page 7]

Internet Draft       SNMP Application Level Gateway        December 1998

  4.2. Translating IP address type

     The basic requirement from SALG-PAT is that it will be able to
     detect IP addresses in the SNMP packets payload.  Once an IP
     address is detected, SALG-PAT should check the translation table
     and decide whether this address should be translated.  If so, the
     4 bytes representing the IPv4 address should be replaced by the
     translated address, and the UDP checksum should be adjusted.

     Therefore, SALG-PAT should parse the ASN.1/BER encoding, looking
     for an IP address type.  If it sees a different object type it can
     jump to the beginning of the next object, unless the object is a
     SEQUENCE Of.  In that case the sequence should be parsed as it
     may contain an IP address type inside.  If an object is of type
     IP address, the translation table is checked to see if this
     address needs to be translated, and if so what the new value
     should be.  The translating function then should replace the 4
     octets with the new address, and continue to parse the packet.

  4.3. General MIB depended translation

     For different applications it may be necessary to translate IP
     addresses that are not encoded in the standard way.  It may be a
     part of a proprietary or a private MIB, which uses some other way
     to represent an IP address (Integers or ASCII).  In that case
     some external information is needed, which states the OID of the
     objects that are IP addresses and the way they are encoded.  The
     translation function, then, scans the packet for these specific
     OIDs, checks the translation table and replaces the data
     if needed.  Note that  since OIDs do not have a fixed size
     this search is much more computationally consuming,  and the
     lookup operation may be very expensive.

  4.4. Forwarding tables, and IP address type as a table index

     IP address type is used in the standard MIB-II (as defined in RFC
     1213) as the index (or part of the index) of several tables.
     Some of the proprietary MIBs may also use it, since this is a very
     convenient way to store information related to IP addresses.
     The following MIB-II tables have IP address type in their indexes:
     atTable, ipAddrTable, ipRouteTable, tcpConnTable, udpConnTable,

     The problem now is that if the manager is trying
     to retrieve a specific value from one of these tables using the

Raz & Sugla                                                     [Page 8]

Internet Draft       SNMP Application Level Gateway        December 1998

     IP address as an index, it should use the local address and not
     the translated one.  If the translated address is used then the
     index should be translated by SALG-PAT.  However, if the access
     to the table is done in order to get the entire table, or the
     next entry in the table, such a translation may result in an
     unpredicted result.  Note that in such cases translation of the
     queries is also required.  A more detailed discussion of the need
     and ability to translate queries can be found in Section 4.5.

     The ability to translate IP addresses that are part of the tables
     indexes is thus another required feature of SALG-PAT.  In this
     case the OID of the table should be predefined (by parsing the
     MIBs offline).  This is a special case of the General MIB
     depended translation discussed in the last subsection.  In this
     case the encoding of the address is known (and different from the
     IP address type).  For example the IP address is
     encoded as 87 B4 8C CA when it is IP address type (each byte is a
     number), and 81 40 81 34 81 0C 81 4A as an IP address index to a
     table (this is due to the OID encoding scheme).

     In this case the function searches for objects with an OID that
     matches one of the OIDs in the translating table.  If such an
     object is found the next four OID numbers (it may be four to
     eight bytes, depending on the ranges of the specific IP address)
     of the OID are checked in the IP translation tables, and replaced
     if needed.  This mechanism allows us to replace table entries in
     MIB tables indexed by IP addresses.  A similar but a bit more
     complicated mechanism, can handle tables that are indexed by more
     than one IP address (like tcpConnTable).

  4.5. Full transparency and forward/backward translation

     As described before, making NAT completely transparent to all
     management applications may be a very hard task.  In some cases
     it may also be undesirable.  A big part of the manual management
     is done by performing a telnet session to the appropriate device,
     and changing some of the local configuration data.  This data
     contains local addresses.  Therefore, it is clear that the full
     address structure should be available to the administrators of
     the network.  The main purpose of SALG-PAT is to be a transparent
     IP address translation mechanism for the automated discovery and
     management tools.  This raises the questions of how to use
     SALG-PAT, what information to translate, and what not.  If we
     only need the basic IP address type translation then we only need
     to translate packets that are going from the managed network to
     the management station (i.e.  GetResponse and Trap packets),
     since they are the only ones containing IP addresses.  However, if
     we need to use the general OID translation, and in particular the

Raz & Sugla                                                     [Page 9]

Internet Draft       SNMP Application Level Gateway        December 1998

     table indexes, we must also translate outgoing packets.

     5.0 Package size and UDP checksum

     Changing the IP address in the payload should not change the size
     of a packet, as we only replace 4 bytes by 4 bytes.  General MIB
     translation may require a change in the size as a different
     number of bytes may be used to encode different IP addresses.
     This is highly undesirable.
     The BER encoding allows the use of both short and long
     length encoding to represent a small index (i.e.  smaller than
     127).  Therefore, in the table index case one can always
     translate to long encoding.  As a result, the encoded length will
     not decrease.  However if a byte smaller than 127 in an IP
     address is translated to a value bigger than 127, an additional
     byte may be required (this depends on the encoding used by the
     agent application).  This will require additional changes in the
     headers (UDP and IP).  In any case the UDP checksum should be
     adjusted when making an IP translation.  We can use the algorithm
     from [SE 98], but a small modification must be introduced as the
     4 bytes may start on an odd position.  The following C code
     adjusts the checksum to a replacement of one byte in an odd or
     even position:

     void checksumbyte(unsigned char *chksum, unsigned char *optr,
     unsigned char *nptr, int odd)
     /* assuming: unsigned char is 8 bits, long is 32 bits,
        we replace one byte by one byte in an odd position.
       - chksum points to the chksum in the packet
       - optr points to the old byte in the packet
       - nptr points to the new byte in the packet
       - odd is 1 if the byte is in an odd position 0 otherwise
     {  long x, old, new;
        x=~x & 0xFFFF;
        if (odd) old=optr[0]*256; else old=optr[0];
        x-=old & 0xFFFF;
        if (x<=0) { x--; x&=0xFFFF; }
        if (odd) new=nptr[0]*256; else new=nptr[0];
        x+=new & 0xFFFF;
        if (x & 0x10000) { x++; x&=0xFFFF; }
        x=~x & 0xFFFF;
        chksum[0]=x/256; chksum[1]=x & 0xff;}

     Unlike TCP, the UDP checksum can be set to 0, which makes all the
     applications ignore it.  This can be used by SALG-PAT if the

Raz & Sugla                                                    [Page 10]

Internet Draft       SNMP Application Level Gateway        December 1998

     computational resources are limited.

  6.0. Limitations of SALG-PAT

     As described before, making the address translation completely
     transparent to all management application is not an achievable
     task.  Many times system administrators use the telnet utility
     in order to configure the managed devices in the managed domain.
     In such cases address translation cannot be done, and
     the administrator must be aware that a translation takes place.

  6.1. Privacy, security, and debugging considerations

     We assume that all the management information is sent on the
     clear, i.e.  without encryption and/or authentication.  If such
     encryption tools are used, then the SALG-PAT must have access to
     the keys/protocols in order to be able to perform the translation
     and/or to verify authentication.  This should not be a problem
     since in general there is only one source for the management
     applications (i.e.  these type of applications are not run by
     general users).  However, the complexity and resources needed to
     perform the translation under these conditions will be much

  6.2. Translation of fragmented UDP packets

     As described in [SE 98], fragments of UDP packets do not carry the
     destination/source port number with them.  In order to parse an
     SNMP packet the complete PDU must be built, and then sent to the
     translation function.  Note that in an extreme case,
     fragmentation may cause an IP address type to be partitioned into
     two different fragments.  The good news is, however, that usually
     the SNMP agents are aware of the MTU, and the SNMP packets are
     usually relatively small.

  7.  SNMP versions

     In this section we briefly describe some of the most significant
     changes related to the newer versions of SNMP.  A very good
     description of the different versions can be found in:

  7.1 SNMP Version 2

     The name SNMP Version 2 refers to a set of 12 documents (RFCs
     1441-1452), that describe a new and enriched version of SNMP.

Raz & Sugla                                                    [Page 11]

Internet Draft       SNMP Application Level Gateway        December 1998

     However, some of the new features were not commonly accepted,
     which resulted in various subversions (such as SNMPv2c, SNMPv2u,
     and SNMPv2*).  The consensus of the SNMPv2 working group was
     published in RFCs 1902-1908 in 1996 and is referred to as

     The basic encoding of the PDU, including the use of the IP
     address type, is very much similar to SNMPv1.  Therefore, the
     principles of SALG-PAT as described in Sections 4 and 5 are valid
     for SNMPv2c.

     One of the main purposes of this version was to add security
     features, such as authentication, and privacy to SNMP.  When
     presented, these security features can prevent the use of
     SALG-PAT as described in Section 6.  It turns out that the
     specifications of these features were very controversial, and
     this was one of the main problems that prevented SNMPv2 from
     becoming widely accepted.

  7.2 SNMPv3

     SNMP Version 3 (SNMPv3) is a new standard being proposed.  This
     version of the protocol is a combination of user-based security,
     the protocol operations and data types from SNMPv2p, and support
     for proxies.  The security is based on the one found in SNMPv2u
     and SNMPv2*, and updated after much review.  The documents
     defining this protocol are described in the RFCs 2261-2265.  The
     use of SALG-PAT for SNMPv3 is not covered by this document.

  8. Current implementations

     The SNMP application level gateway for payload address
     translation was implemented in Bell-Labs.  The C code is running
     on a Solaris machine.  The solution described in Figure 3, where
     SALG-PAT was combined with the NAT implementation of Lucent's
     RABU, was deployed in a large network management service

  9. Acknowledgments

     We thank Brett A.  Denison for his contribution to the work that
     led to this document.  We also thank Pyda Srisuresh, for the
     support, encouragement, and advice through out the work on this

Raz & Sugla                                                    [Page 12]

Internet Draft       SNMP Application Level Gateway        December 1998


     [SH 98]     P.  Srisuresh, and M. Holdrege, "The IP Network Address
                 Translator (NAT) terminology and considerations",
                 <draft-ietf-nat-terminology-01.txt> - Work in progress

     [SE 98]     P.  Srisuresh, and K.  Egevang, "Traditional IP Network
                 Address Translator (Traditional NAT)",
                 <draft-ietf-nat-traditional-00.txt> - Work in progress

     [RFC-1631]  P.  Srisuresh, and K.  Egevang, "The IP Network Address
                 Translator (NAT)", RFC 1631 February 1998 or its

     [RFC-1066]  McCloghrie K., and M.  Rose, "Management Information
                 for Network Management of TCP/IP-based internets", RFC
                 1066 August 1988 or its successor.

     [RFC-1067]  Case, J., M.  Fedor, M.  Schoffstall, and J.  Davin,
                 Simple Network Management Protocol", RFC 1067, August
                 or its successor.

     [RFC-1466]  E. Gerich, "Guidelines for Management of IP Address
                 RFC 1466, May 1993 or its successor.

     [RFC-768]   J.  Postel, "User Datagram Protocol (UDP)", RFC 768 or

     [RFC-950]   J.  Mogul, J.  Postel, "Internet Standard Subnetting
                 Procedure", RFC 950 or its successor.

     [RFC 1157]  J.  Case, M.  Fedor, M.  Schoffstall, and J.  Davin,
                 Simple Network Management Protocol", RFC 1157, May

     [RFC 1213]  K. McCloghrie, and M.T. Rose, "Management Information
Base for Network
                 Management of TCP/IP-based internets:MIB-II", RFC 1213
                 Mars 1991, or its successor.

     [RFC 1215]  M.T. Rose, "Convention for defining traps for use with
the SNMP",
                 RFC 1215 Mars 1991, or its successor.

     [RFC 1155]  K. McCloghrie, and M.T. Rose, "Structure and
identification of
                 management information for TCP/IP-based internets", RFC
                 May 1990, or its successor.

     [RFC 2003]  C. Perkins, "IP Encapsulation within IP", RFC 2003,
                 1996 or its successor.

Raz & Sugla                                                    [Page 13]

Internet Draft       SNMP Application Level Gateway        December 1998

     [RFC 2261]  Harrington, D., Presuhn, R., and B.  Wijnen, "An
                 Architecture for describing SNMP Management
                 RFC 2261, January 1998.

     [RFC 2262]  Case, J., Harrington, D., Presuhn, R., and B.  Wijnen,
                 "Message Processing and Dispatching for the Simple
                 Management Protocol (SNMP)", RFC 2262, January 1998.

     [RFC 2263]  SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. RFC
                 January 1998.

     [RFC 2264]  User-based Security Model (USM) for version 3 of the
                 Network Management Protocol (SNMPv3). U. Blumenthal, B.
                 RFC 2264, January 1998.

     [RFC 2265]  Wijnen, B., Presuhn, R., and K.  McCloghrie,
                 Access Control Model for the Simple Network Management
                 Protocol (SNMP)", RFC 2265, January 1998.

     [ISO-8824]  International Organization for Standardization,
                 Information Technology:  Abstract Syntax Notation One
                 (ASN.1):  Specification of Basic Notation, ISO/IEC

     [ISO-8825]  International Organization for Standardization,
                 Information Technology:  ASN.1 Encoding Rules:
                 Specification of Basic Encoding Rules (BER), Canonical
                 Encoding Rules (CER) and Distinguished Encoding Rules
                 (DER), ISO/IEC 8825-1:  1995.

     [Mi 97]     M.  A.  Miller, Managing Internetworks with SNMP,
                 M&T Books,1997.

     [PM 97]     D.  Perkins, and E.  McGinnis, Understanding SNMP MIBs,
                 Prentice-Hall, 1997.

  Authors' Addresses

     Danny Raz
     Bell Labs,  Lucent Technologies
     Room 4G-637
     101 Crawfords Corner Rd
     Holmdel, NJ 07733-3030

Raz & Sugla                                                    [Page 14]

Internet Draft       SNMP Application Level Gateway        December 1998


     Voice: (732) 949-6712
     Fax:   (732) 949-0399

     Binay Sugla
     Bell Labs,  Lucent Technologies
     Room 4F-621
     101 Crawfords Corner Rd
     Holmdel, NJ 07733-3030

     Voice: (732) 949-0850
     Fax:   (732) 949-0399

Raz & Sugla                                                    [Page 15]