[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3103

INTERNET DRAFT                                       Michael Borella
Expires August 1999                                  David Grabelsky
                                                     3Com Corp.

                                                     Jeffrey Lo
                                                     Kunihiro Tuniguchi
                                                     NEC USA





               Realm Specific IP: Protocol Specification
                 <draft-ietf-nat-rsip-protocol-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This draft presents a protocol that enables an alternative to network
   address translation (NAT).  Realm-Specific IP (RSIP) defines an
   architecture in which an RSIP server is a multi-homed host connecting
   two routing realms.  An RSIP client in the first routing realm may be
   assigned a plurality of routing parameters from the second routing
   realm.  The RSIP client will be allowed to create packets using these
   parameters, and tunnel them across the first routing realm.  For
   example, more than one host from a private address space using RSIP
   may share one or more public address.  Unlike NAT, RSIP does not
   break the end-to-end integrity of protocols.  We present a general,



Borella et al.             Expires August 1999                  [Page 1]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   extensible negotiation protocol to be operated between RSIP clients
   and servers which facilitates the assignment of parameters and
   resources from the server to the client. This draft is a
   generalization of the techniques introduced in the drafts <draft-
   borella-aatn-dnat-01.txt> (DNAT) and <draft-ietf-nat-hnat-00.txt>
   (Host-NAT).

1.  Introduction

   Network Address Translation (NAT) has gained popularity as a method
   of separating public and private address spaces, and alleviating
   network address shortages.  A NAT translates the addresses of packets
   leaving a first routing realm to an address from a second routing
   realm, and performs the reverse function for packets entering the
   first routing realm from the second routing realm.  This translation
   is performed transparently to the hosts in either space, and may
   include modification of TCP/UDP port numbers as well as IP addresses.

   While a NAT does not require hosts to be aware of the translation, it
   will require an application layer gateway (ALG) for any protocol that
   transmits IP addresses or port numbers in packet payloads (such as
   FTP).  Additionally, a NAT will not work with protocols that require
   IP addresses and ports to remain unmodified between the source and
   destination hosts or protocols that prevent such modifications to
   occur (such as some IPSec modes).

   An alternative to a transparent NAT is an architecture that allows
   the clients within the first (e.g., private) routing realm to
   directly use addresses and other routing parameters from the second
   (e.g., public) routing realm.  This form of Realm-Specific IP (RSIP)
   requires that an RSIP-server (a router or gateway between the two
   realms) assign at least one address from the second routing realm,
   and perhaps some other resources, to each RSIP-client host in the
   first routing realm that needs to establish end-to-end connectivity
   to a host, entity or device in the second routing realm. Thus, the
   second routing realm is not transparent to RSIP-client, but this
   system allows packets to maintain their integrity from RSIP-client to
   destination.  In order to resolve addressing and routing ambiguities
   in the first routing realm, all publicly routed packets are tunneled
   between RSIP-client and the RSIP-server, or tunneled such that the
   RSIP-server can perform a NAT function on the outer IP header only.
   ALGs are not required in the RSIP-server.

   A disadvantage to RSIP is that it requires that hosts be modified so
   that they tunnel externally-bound packets and place some number of
   layer three, layer four or other values from those assigned by the
   RSIP-server in each packet bound for the second routing realm.




Borella et al.             Expires August 1999                  [Page 2]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   This draft discusses a method for assigning parameters to an RSIP-
   client from an RSIP-server.  In particular, this method is a
   generalization of the techniques introduced in the drafts <draft-
   borella-aatn-dnat-01.txt> (DNAT) and <draft-ietf-nat-hnat-00.txt>
   (Host-NAT).

   1.1.  Specification of Requirements

      The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
      NOT", "SHALL", and "SHALL NOT", and "MAY" that appear in this
      document are to be interpreted as described in [1].

2.  Architecture

   For simplicity, for the remainder of this document we will assume
   that the RSIP-clients in the first routing realm (network) use
   private (network 10) IP addresses, and that the second routing realm
   (network) uses public IP addresses.  The RSIP-server connects the
   public and private realms and contains interfaces to both.  Other NAT
   terminology found in this document is defined in [2].

   The diagram below describes an exemplary reference architecture for
   RSIP. Some number of RSIP-clients are attached via a private network
   to an RSIP-server, which also acts as a router or gateway between the
   private and public networks. This router has been assigned some
   number of public addresses that it may use or allocate for use on the
   public network.

   +-------------+
   | RSIP-client |
   |       1     +--+
   |   10.0.0.2  |  |                 +-------------+
   +-------------+  |        10.0.0.1 |             |   149.112.240.0/24
                    +-----------------+ RSIP-server +-------------------
   +-------------+  |                 |             |
   | RSIP-client |  |                 +-------------+
   |       2     +--+     private                     public
   |   10.0.0.3  |  |     network                     network
   +-------------+  |
                    |
                    |
                   ...

   RSIP MAY be based on either the Basic NAT or the NAPT model.  In the
   Basic NAT model, a unique public IP address is assigned to each
   private NAT client that is actively communicating with the public
   network.  Only one NAT client uses a given public address.  In the
   NAPT model, one public address is shared by one or more NAT clients.



Borella et al.             Expires August 1999                  [Page 3]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   One or more NAT clients may use the same public address by limiting
   the ports that they use to disjoint subsets of the port space.  The
   NAT server assigns these disjoint port sets to each host, along with
   the public IP address.  For the remainder of this document we will
   assume the NAPT model.

   For purposes of illustration, we will provide a brief example of the
   transport operation of RSIP with respect to the above architecture.
   We assume that RSIP-client 10.0.0.2 has been assigned public address
   149.112.240.10 and port set 10000-10015 (the actual mechanism for
   this assignment is discussed below).  Packets transmitted from this
   client to a WWW server at the external address of 128.153.4.3 will be
   appear as follows on the private network:

            Outer IP        Inner IP      TU Ports
        +--------------+----------------+----------+
   Src: |   10.0.0.2   | 149.112.240.10 |  10000   |
        +--------------+----------------+----------+
   Dst: |   10.0.0.1   |   128.153.4.3  |    80    |
        +--------------+----------------+----------+

   Note that 10000 was chosen arbitrarily from the port set by the
   kernel port selection code of the RSIP-client.  Upon reaching the
   RSIP-server, the outer IP header is stripped off, and the remaining
   packet is transmitted on the public network.  Incoming packets to the
   RSIP-client may be demultiplexed based on layer three, layer four, or
   other parameters, and tunneled from the RSIP-server to the RSIP-
   client.

   Note that the architecture and protocols for RSIP may allow for
   cascading of RSIP-servers.  For example, RSIP-server A may assign
   some number of public IP addresses and port sets to RSIP-server B,
   which is entirely inside of the private network.  RSIP-server B will
   then assign some of these addresses and port sets to private hosts.
   This architecture conforms to the model in which a corporation (in
   charge of RSIP-server B) buys public network access from an ISP (in
   charge of RSIP-server A). In this scenario, RSIP-server B and end
   hosts within the corporation could be considered the RSIP-client of
   RSIP-server A and RSIP-server B respectively.

   2.1.  RSIP Parameter Negotiation

      An RSIP-client initiates a binding request with an RSIP-server by
      transmitting a REGISTER message.  This allows the RSIP-server to
      become aware of the RSIP-client.  The RSIP-server will assign a
      unique identifier to the RSIP-client.  Negotiation of tunnel type
      may also occur.




Borella et al.             Expires August 1999                  [Page 4]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      An RSIP client must then use the ASSIGN message to request one or
      more IP addresses, port sets and/or other parameters from the
      public realm.  Upon these parameters will be assigned with a lease
      time, after which their assignment must be renewed.

      At this point, the RSIP-client may use the assigned parameters to
      transmit packets to the public network.

      If an RSIP-client no longer needs some parameters, that it has
      been assigned, it may release them by transmitting a FREE message
      to the RSIP-server, and specifying the parameters to release
      within that message.

      If an RSIP-client no longer needs to communicate with the public
      network, it may use the DE_REGISTER message to notify the RSIP-
      server of such.  Use of the DE-REGISTER message effectively
      releases all of the RSIP-client's parameters.  It must register
      and be assigned parameters once more before it transmits packets
      to the public network again.

      The ERROR message may be used at any time by the RSIP-server to
      indicate that an RSIP-client's request was denied or malformed.

   2.2.  Operation

      In the case of Basic-NAT-Like operation, the number of IP
      addresses requested in an ASSIGN may be more than one, but an
      RSIP-client MAY NOT be assigned port sets.

      In the case of NAPT-like operation, an RSIP-client MUST request
      one or more port sets in ASSIGN messages that contain an IP
      address, but only one IP address may be requested per ASSIGN
      message.  If more than one IP address is desired, the request MUST
      be issued as two independent ASSIGN requests, and each will be
      given a different binding.

      If the resources requested are temporarily unavailable, an RSIP-
      server MAY either commit a subset of the resources requested or
      return an ERROR message indicating that the requested resource was
      temporarily unavailable.  An RSIP-client is free to attempt
      another ASSIGN request for the same resource after an interval of
      time.

      An RSIP-server MAY allow freeing to be done on a subset of an
      assigned range, address range in the case of traditional NAT-like
      operation and port range in the case of NAPT-like operation. Child
      ranges as a result of a subset free MUST retain the same binding.
      If an RSIP-server receives a FREE message that refers to



Borella et al.             Expires August 1999                  [Page 5]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      parameters not assigned to the originating RSIP-client, an ERROR
      message indicating that the parameter range was invalid MUST be
      returned.  If an RSIP server receives a FREE message referring to
      an unknown binding, an ERROR message indicating that the binding
      is unknown MUST be returned.

      If an RSIP-client wishes to extend the duration of an existing
      binding, an ASSIGN request with the same Bind ID and the desired
      extension duration MAY be sent. The RSIP-server SHOULD either
      grant the request, grant a smaller duration than that requested or
      deny the request. If a smaller duration is granted, this duration
      MUST be included in the response message to the ASSIGN request. In
      the case when the request is denied, the appropriate error
      response MUST be sent.

   2.3.  Subnet Query

      In some cases it is not possible for an RSIP-client to know
      whether a packet should be tunneled to the RSIP-server or
      transmitted using the local (private) routing realm only. The RSIP
      protocol provides a subnet query mechanism through which an RSIP-
      client may query an RSIP-server to ask whether a particular subnet
      falls within the private domain.  An RSIP-client queries the
      server using the QUERY message with the subnet included in the IP
      address field of the message. The RSIP-server MAY confirm the
      subnet queried or MAY return the whole range of subnets supported
      so as to enable the RSIP-client to cache the entries.  The RSIP-
      server may be manually configured to know the topology of the
      private domain.

   2.4.  Unreliable Transport

      A sequence number field SHOULD be included in all messages if UDP,
      or some other unreliable transport mechanism, is used. The
      sequence number starts with zero in the client's REGISTER message
      and end with a maximum value in the server's DE_REGISTER message.
      This field SHOULD be incremented by one for every request issued.
      Responses MUST include the same sequence number as that of the
      request which it acknowledges.

      If an RSIP-client does not receive a response from the RSIP-server
      for a request, a new request with the same sequence number MAY be
      issued after an interval of time.  An RSIP-server receiving a
      request with a sequence number smaller than what it previously
      received SHOULD ignore the request.  Pipelining of requests and
      aggregation of responses are not allowed.

      Sequence number wraparound is highly unlikely, however it must be



Borella et al.             Expires August 1999                  [Page 6]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      considered in both the RSIP clients and servers.

   2.5.  Parameter Assignment Transport and Mechanisms

      In order to assign parameters to the RSIP-client from the RSIP-
      server, a transport protocol and an assignment mechanism must be
      used. Design of the end-to-end NAT protocol aims to be transport
      independent, so that existing transport protocols such as UDP or
      TCP can be used.

      The assignment mechanisms MAY be DHCP, COPS, DIAMETER or some
      similar protocol.  While these protocols would allow nearly-
      arbitrary parameters to be assigned to the RSIP-clients, our
      current goal is to determine the parameters that are necessary for
      RSIP to operate in full generality, and define a basic protocol
      with which these parameters can be negotiated and assigned.  Once
      the fundamental requirements of RSIP parameter assignment are
      specified, it may either be integrated into an existing protocol
      or left alone as its own protocol.


3.  General Message and Parameter Formats

   In this section we define the general message and parameter format.
   Codes for each parameter and message types will be discussed the
   following sections.  Within an RSIP control packet, the parameters
   MAY appear in any order, but it is recommended that required
   parameters precede all optional parameters.

   The general message format is shown below.

       1 byte      Variable        Variable
   +-----------+---------------+-------------------
   |    Type   |  Parameter 1  |  Parameter 2 ...
   +-----------+---------------+-------------------

   The type field indicates how the parameters are to be interpreted
   (e.g., request, response, error, etc.).

   The general format of all parameters is shown below.

    1 byte   2 bytes  'Length' bytes
   +------+----------+----------------------
   | Code |  Length  | Parameter value ...
   +------+----------+----------------------

   All parameters consist of a fixed portion and a variable portion.
   The fixed portion is a 1 byte code value and a 2 byte length. The



Borella et al.             Expires August 1999                  [Page 7]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   remaining portion of the parameter is the parameter value, the length
   which is the number of bytes indicated by the length field.

4.  Parameter Types and Formats

   Number of IP Addresses

        Code   Length    Number of Addresses
      +------+--------+----------------------+
      |  0   |    1   |      (1 byte)        |
      +------+--------+----------------------+

      Used in ASSIGN messages to request a particular number of public
      addresses to be assigned.

   Number of Ports

        Code   Length    Number of Ports
      +------+--------+-------------------+
      |  1   |    1   |      (1 byte)     |
      +------+--------+-------------------+

      Used in ASSIGN messages to request a particular number of ports to
      be assigned.

   IP Address

        Code            Length                     IP Address
      +------+-------------------------+-------------------------------+
      |  2   |       Multiple of 4     |      (Multiple of 4 bytes)    |
      +------+-------------------------+-------------------------------+

      This field represents the IPv4 address(es) negotiated.  More than
      one IP addresses MAY be included after the length field; thus, the
      length field MUST be a multiple of 4.

   IP Address Range

        Code          Length            Low Address    High Address
                                               (May repeat)
      +------+------------------------+-----------------------------+
      |  3   |     Multiple of 8      |  (4 bytes)   |   (4 bytes)  |
      +------+------------------------+-----------------------------+

      In cases where the number of IPv4 addresses negotiated is large
      and contiguous, the IPv4 address range parameter is used to
      represent the range.  Multiple ranges MAY be represented within a
      single IP Address Range parameter.



Borella et al.             Expires August 1999                  [Page 8]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   Port Range

        Code         Length             Low Port    High Port
                                            (May Repeat)
      +------+-----------------------+-----------------------+
      |  4   |     Multiple of 4     | (2 bytes) | (2 bytes) |
      +------+-----------------------+-----------------------+

      The port range MUST be contiguous and is inclusive. Multiple
      ranges MAY be represented within a port range parameter.

   Lease Time

        Code   Length       Lease Time
      +------+--------+-------------------+
      |  5   |    4   |      (4 bytes)    |
      +------+--------+-------------------+

      Number of seconds that an RSIP-client may retain the parameters
      assigned by an RSIP-server.

   Error

        Code   Length         Error
      +------+--------+-------------------+
      |  6   |    2   |      (2 bytes)    |
      +------+--------+-------------------+

      These error codes allow an RSIP-server to inform an RSIP-client
      why a particular request has failed.

      0 Unknown Error - An error that cannot be identified has occurred
      1 Bind ID Not Found -  The request refers to an invalid Bind ID.
      2 Client ID Not Found - The request refers to an invalid Client ID.
      3 Invalid Message - The request does not contain an mandatory
           parameter or cannot be parsed.
      4 NAT Type Not Supported - The request refers to a NAT type not
           supported by this NAT-server.
      5 Not Authorized - The RSIP-client is not authorized to make the
           request.
      6 Resource Temporarily Unavailable - The request has asked for a
           resource (e.g., addresses, ports) that the RSIP-server
           is not currently able to grant.
      7 Tunnel Type Not Supported - The request refers to a tunnel type
           that the RSIP-server does not support.
      8 Wrong Sequence Number - The request used a sequence number that
           the RSIP-server did not expect.




Borella et al.             Expires August 1999                  [Page 9]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   Client ID

        Code   Length        Client ID
      +------+--------+-------------------+
      |  7   |    4   |      (4 bytes)    |
      +------+--------+-------------------+

      A unique number assigned by an RSIP-server when an RSIP-client
      registers with the server. It is used to identify the RSIP-client.

   Bind ID

        Code   Length        Bind ID
      +------+--------+-------------------+
      |  8   |    4   |      (4 bytes)    |
      +------+--------+-------------------+

      The Bind ID is a unique number allocated for each new assignment.
      It is returned as part of an ASSIGN response to a successful
      ASSIGN request.  Subsequent message exchanges pertaining a bind
      MUST include its Bind ID.  When a or range of parameters is
      assigned to an RSIP-client, the parameter is said to be 'bound' to
      that client. More than one bind with different Bind IDs may be
      established between an RSIP-client and RSIP-server pair. A binding
      will expire when its lease time runs out or when the RSIP-client
      de-registers itself with the RSIP-server.

   Sequence Number

      Code    Length       Sequence Number
      +------+--------+-------------------+
      |  9   |    1   |      (1 byte)     |
      +------+--------+-------------------+

      If the transport protocol is connectionless. such as UDP, the
      sequence number field MUST be included as a means to order the
      messages and/or match requests and responses.

   Tunnel Type

        Code   Length   Tunnel Type
      +------+--------+-------------+
      |  10  |    n   |  (n bytes)  |
      +------+--------+-------------+

      The type of tunnel used between an RSIP-client and an RSIP-server.
      Values are assigned as follows:




Borella et al.             Expires August 1999                 [Page 10]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      0  Reserved
      1  IP-IP
      2  GRE
      3  L2TP
      4  IPSec

      NOTE: More tunnel types should be defined, especially for the
      different variations of IPSec.

   NAT Type

        Code   Length     NAT Type
      +------+--------+-------------+
      |  11  |    n   |  (n bytes)  |
      +------+--------+-------------+

      The type of NAT-like operation that the RSIP-server will perform.
      The following values have been assigned:

      1 Traditional NAT
      2 NAPT
      3 Twice NAT

   Vendor Specific Parameter

        Code    Length    Vendor ID     Subcode    Parameter
      +------+----------+------------+-----------+-----------+
      |  12  |   n+4    | (2 bytes)  | (2 bytes) | (n bytes) |
      +------+----------+------------+-----------+-----------+

      This parameter allows vendors to specify vendor specific
      information. The Vendor ID field the vendor-specific ID assigned
      by IANA.  Subcodes are defined and used by each vendor.


5.  Message Type

   Apart from the message type field, which MUST appear at the beginning
   of each message, other parameters MAY appear in any order.  Note that
   message sequencing MAY need to be introduced depending on the
   transport.  The following message types are defined in simple BNF.
   Required parameters are enclosed in <> and MUST appear.  Optional
   parameters are enclosed in [] and MAY appear.


   ERROR Response

      An ERROR response is used to provide error responses to an RSIP-



Borella et al.             Expires August 1999                 [Page 11]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      client message.  The message type is 1.

         <ERROR Response>::= <Message Type> <Error Parameter>
                             [<Sequence Number>][<Client ID>]
                             [<Bind ID>]

   REGISTER

      The REGISTER message is used by an RSIP-client to register with an
      RSIP-server.  An RSIP-client MUST register before it requests
      parameters from the RSIP-server.  The message type is 2. The RSIP-
      client MAY list all of the tunnel types and NAT types supported.
      The default tunnel type is IP-IP, and the default NAT type is
      NAPT.

         <REGISTER Request> ::= <Message Type>
                                [<Sequence Number>][<TunnelType>...]
                                [<NAT Type>...]

         <REGISTER Response> ::= <Message Type> <Client ID>
                                 [<Sequence Number>][<Tunnel Type>]
                                 [<NAT Type>...]

   DE_REGISTER

      The DE_REGISTER message is used by an RSIP-client to de-register
      with an RSIP-server.  The message type is 3.

         <DE_REGISTER Request> ::= <Message Type> <Client ID>
                                   [<Sequence Number>]

         <DE_REGISTER Response> ::= <Message Type> <Client ID>
                                    [<Sequence Number>]

   ASSIGN

      The ASSIGN message is used by an RSIP-client to request parameter
      assignments. The message type is 4.  If a client is given a single
      IP address, a port range MUST be specified if NAPT is the NAT
      type.  If a client is given a range of n IP addresses, this
      parameter MUST be followed by exactly n port range parameters.
      The Client ID field MUST be included, otherwise, an RSIP-server
      MUST return an ERROR message with the "Client ID not found" error
      parameter. The lease time parameter MAY be included in an
      assignment request as an indication of a desired bind duration.
      If a lease time is not requested by an RSIP-client, an RSIP-server
      SHOULD assign a default lease time.




Borella et al.             Expires August 1999                 [Page 12]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


         <ASSIGN Request> ::= <Message Type> <Client ID>
                              [<Sequence Number>][<NAT Type>]
                              [<Number of Ports>] [<Number of IP Addr>]
                              [<Lease Time>]

         <ASSIGN Response> ::= <Message Type> <Client ID> <BindID>
                               [<Sequence Number>][<Port Range>...]
                               [<IP Address>][<Lease Time>]

         <ASSIGN Response> ::= <Message Type> <Client ID> <BindID>
                               [<Sequence Number>][<IP Address Range>]
                               [<Port Range 1>...<Port Range n>]
                               [<Lease Time>]

   FREE

      The FREE message is used by an RSIP-client to free parameter
      assignments.  The message type is 5.  If no parameters are
      specified in a FREE message, then all of the parameters associated
      with the Bind ID MUST be freed.

         <FREE Request> ::= <Message Type> <Client ID> <Bind ID>
                            [<Sequence Number>][<Port Range>...]
                            [<IP Address Range>...][<IP Address> ...]

         <FREE Response> ::= <Message Type> <Client ID> <Bind ID>
                             [<Sequence Number>][<Port Range>]
                             [<IP Address Range>...][<IP Address>...]

   QUERY

      A QUERY message is used by an RSIP-client to request if a subnet
      is supported by an RSIP-server.  The message type is 6.

         <QUERY Request> ::= <Message Type> <Client ID> <IP address>
                             [<Sequence Number>]

         <QUERY Response> ::= <Message Type> <Client ID> <IP address>
                             [<Sequence Number>]

6.  To Do

   - Distinguish request and response messages
   - Examples


7.  Security Considerations




Borella et al.             Expires August 1999                 [Page 13]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   RSIP, in and of itself, does not provide security.  It may provide
   the illusion of security or privacy by hiding a private address
   space, but security and privacy can only be ensured by the proper use
   of strong encryption.

   An RSIP implementation must be guarded against potential denial- of-
   service attacks.  A malicious RSIP-client may be able to determine
   the parameters associated with another RSIP-client via packet
   sniffing.  An attacker could free the resources allocated by the
   RSIP-server by spoofing a FREE request.  Negotiation between an RSIP
   client and server should be secured with an appropriate
   authentication mechanism.

   RSIP-servers SHOULD NOT forward packets from a RSIP-client without
   checking the validity of the source IP address and source port
   number, as well as any other relevant parameters.  Other necessary
   policy based routing checks SHOULD also be made.  Improper use of
   source IP address, source port number, or any RSIP-client using a
   resource or parameter assigned to a different RSIP-client are
   auditable events.  An RSIP-server SHOULD log negotiation transactions
   in which a client attempts to use an improper Client ID or Bind ID.


8.  References

   [1] S. Bradner. "Key words for use in RFCs to indicate requirement
      levels," RFC 2119, Mar. 1997.

   [2] P. Srisuresh, Matt holdrege, "NAT: Terminology and
      considerations" Internet Draft <draft-ietf-nat-
      terminology-01.txt>, Work in progress.

9.  Acknowledgements

   The authors would like to thank Pyda Srisuresh and Rick Cobb for
   their input.

10.  Authors' Addresses

   Michael Borella
   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 342-6093
   mike_borella@3com.com

   David Grabelsky



Borella et al.             Expires August 1999                 [Page 14]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 222-2483
   david_grabelsky@3com.com

   Jeffrey Lo
   NEC USA
   C&C Research Labs.
   110 Rio Robles
   San Jose, CA 95134
   (408) 943 3033
   jlo@ccrl.sj.nec.com

   Kunihiro Taniguchi
   NEC USA
   C&C Research Labs.
   110 Rio Robles
   San Jose, CA 95134
   (408) 943 3032
   taniguti@ccrl.sj.nec.com


   Copyright (c) The Internet Society (1999). All Rights Reserved.

      This document and translations of it may be copied and furnished to
      others, and derivative works that comment on or otherwise explain it
      or assist in its implementation may be prepared, copied, published
      and distributed, in whole or in part, without restriction of any
      kind, provided that the above copyright notice and this paragraph are
      included on all such copies and derivative works. However, this
      document itself may not be modified in any way, such as by removing
      the copyright notice or references to the Internet Society or other
      Internet organizations, except as needed for the purpose of
      developing Internet standards in which case the procedures for
      copyrights defined in the Internet Standards process must be
      followed, or as required to translate it into languages other than
      English.

      The limited permissions granted above are perpetual and will not be
      revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on an
      "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
      TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
      BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
      HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF



Borella et al.             Expires August 1999                 [Page 15]

INTERNET-DRAFT  Realm Specific IP: Protocol Specification  February 1999


      MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


















































Borella et al.             Expires August 1999                 [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/