rfc3102.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,389 行 · 第 1/5 页

Borella, et al.               Experimental                      [Page 5]

RFC 3102                    RSIP: Framework                 October 2001


2.  Architecture

   In a typical scenario where RSIP is deployed, there are some number
   of hosts within one addressing realm connected to another addressing
   realm by an RSIP gateway.  This model is diagrammatically represented
   as follows:

         RSIP Host             RSIP Gateway                    Host

            Xa                    Na   Nb                       Yb
         [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
                  (  Network   )            (  Network   )

   Hosts X and Y belong to different addressing realms A and B,
   respectively, and N is an RSIP gateway (which may also perform NAT
   functions).  N has two interfaces: Na on address space A, and Nb on
   address space B.  N may have a pool of addresses in address space B
   which it can assign to or lend to X and other hosts in address space
   A.  These addresses are not shown above, but they can be denoted as
   Nb1, Nb2, Nb3 and so on.

   As is often the case, the hosts within address space A are likely to
   use private addresses while the RSIP gateway is multi-homed with one
   or more private addresses from address space A in addition to its
   public addresses from address space B.  Thus, we typically refer to
   the realm in which the RSIP host resides as "private" and the realm
   from which the RSIP host borrows addressing parameters as the
   "public" realm.  However, these realms may both be public or private
   - our notation is for convenience.  In fact, address space A may be
   an IPv6 realm or a non-IP address space.

   Host X, wishing to establish an end-to-end connection to a network
   entity Y situated within address space B, first negotiates and
   obtains assignment of the resources (e.g., addresses and other
   routing parameters of address space B) from the RSIP gateway.  Upon
   assignment of these parameters, the RSIP gateway creates a mapping,
   referred as a "bind", of X's addressing information and the assigned
   resources.  This binding enables the RSIP gateway to correctly de-
   multiplex and forward inbound traffic generated by Y for X.  If
   permitted by the RSIP gateway, X may create multiple such bindings on
   the same RSIP gateway, or across several RSIP gateways.  A lease time
   SHOULD be associated with each bind.

   Using the public parameters assigned by the RSIP gateway, RSIP hosts
   tunnel data packets across address space A to the RSIP gateway.  The
   RSIP gateway acts as the end point of such tunnels, stripping off the
   outer headers and routing the inner packets onto the public realm.
   As mentioned above, an RSIP gateway maintains a mapping of the



Borella, et al.               Experimental                      [Page 6]

RFC 3102                    RSIP: Framework                 October 2001


   assigned public parameters as demultiplexing fields for uniquely
   mapping them to RSIP host private addresses.  When a packet from the
   public realm arrives at the RSIP gateway and it matches a given set
   of demultiplexing fields, then the RSIP gateway will tunnel it to the
   appropriate RSIP host.  The tunnel headers of outbound packets from X
   to Y, given that X has been assigned Nb, are as follows:

            +---------+---------+---------+
            | X -> Na | Nb -> Y | payload |
            +---------+---------+---------+

   There are two basic flavors of RSIP: RSA-IP and RSAP-IP.  RSIP hosts
   and gateways MAY support RSA-IP, RSAP-IP, or both.

   When using RSA-IP, an RSIP gateway maintains a pool of IP addresses
   to be leased by RSIP hosts.  Upon host request, the RSIP gateway
   allocates an IP address to the host.  Once an address is allocated to
   a particular host, only that host may use the address until the
   address is returned to the pool.  Hosts MAY NOT use addresses that
   have not been specifically assigned to them.  The hosts may use any
   TCP/UDP port in combination with their assigned address.  Hosts may
   also run gateway applications at any port and these applications will
   be available to the public network without assistance from the RSIP
   gateway.  A host MAY lease more than one address from the same or
   different RSIP gateways.  The demultiplexing fields of an RSA-IP
   session MUST include the IP address leased to the host.

   When using RSAP-IP, an RSIP gateway maintains a pool of IP addresses
   as well as pools of port numbers per address.  RSIP hosts lease an IP
   address and one or more ports to use with it.  Once an address / port
   tuple has been allocated to a particular host, only that host may use
   the tuple until it is returned to the pool(s).  Hosts MAY NOT use
   address / port combinations that have not been specifically assigned
   to them.  Hosts may run gateway applications bound to an allocated
   tuple, but their applications will not be available to the public
   network unless the RSIP gateway has agreed to route all traffic
   destined to the tuple to the host.  A host MAY lease more than one
   tuple from the same or different RSIP gateways.  The demultiplexing
   fields of an RSAP-IP session MUST include the tuple(s) leased to the
   host.

3.  Requirements

3.1.  Host and Gateway Requirements

   An RSIP host MUST be able to maintain one or more virtual interfaces
   for the IP address(es) that it leases from an RSIP gateway.  The host
   MUST also support tunneling and be able to serve as an end-point for



Borella, et al.               Experimental                      [Page 7]

RFC 3102                    RSIP: Framework                 October 2001


   one or more tunnels to RSIP gateways.  An RSIP host MUST NOT respond
   to ARPs for a public realm address that it leases.

   An RSIP host supporting RSAP-IP MUST be able to maintain a set of one
   or more ports assigned by an RSIP gateway from which choose ephemeral
   source ports.  If the host's pool does not have any free ports and
   the host needs to open a new communication session with a public
   host, it MUST be able to dynamically request one or more additional
   ports via its RSIP mechanism.

   An RSIP gateway is a multi-homed host that routes packets between two
   or more realms.  Often, an RSIP gateway is a boundary router between
   two or more administrative domains.  It MUST also support tunneling
   and be able to serve as an end-point for tunnels to RSIP hosts.  The
   RSIP gateway MAY be a policy enforcement point, which in turn may
   require it to perform firewall and packet filtering duties in
   addition to RSIP.  The RSIP gateway MUST reassemble all incoming
   packet fragments from the public network in order to be able to route
   and tunnel them to the proper host.  As is necessary for fragment
   reassembly, an RSIP gateway MUST timeout fragments that are never
   fully reassembled.

   An RSIP gateway MAY include NAT functionality so that hosts on the
   private network that are not RSIP-enabled can still communicate with
   the public network.  An RSIP gateway MUST manage all resources that
   are assigned to RSIP hosts.  This management MAY be done according to
   local policy.

3.2.  Processing of Demultiplexing Fields

   Each active RSIP host must have a unique set of demultiplexing fields
   assigned to it so that an RSIP gateway can route incoming packets
   appropriately.  Depending on the type of mapping used by the RSIP
   gateway, demultiplexing fields have been defined to be one or more of
   the following:

      -  destination IP address

      -  IP protocol

      -  destination TCP or UDP port

      -  IPSEC SPI present in ESP or AH header (see [RFC3104])

      -  others

   Note that these fields may be augmented by source IP address and
   source TCP or UDP port.



Borella, et al.               Experimental                      [Page 8]

RFC 3102                    RSIP: Framework                 October 2001


   Demultiplexing of incoming traffic can be based on a decision tree.
   The process begins with the examination of the IP header of the
   incoming packet, and proceeds to subsequent headers and then the
   payload.

      -  In the case where a public IP address is assigned for each
         host, a unique public IP address is mapped to each RSIP host.

      -  If the same IP address is used for more than one RSIP host,
         then subsequent headers must have at least one field that will
         be assigned a unique value per host so that it is usable as a
         demultiplexing field.  The IP protocol field SHOULD be used to
         determine what in the subsequent headers these demultiplexing
         fields ought to be.

      -  If the subsequent header is TCP or UDP, then destination port
         number can be used.  However, if the TCP/UDP port number is the
         same for more than one RSIP host, the payload section of the
         packet must contain a demultiplexing field that is guaranteed
         to be different for each RSIP host.  Typically this requires
         negotiation of said fields between the RSIP host and gateway so
         that the RSIP gateway can guarantee that the fields are unique
         per-host

      -  If the subsequent header is anything other than TCP or UDP,
         there must exist other fields within the IP payload usable as
         demultiplexing fields.  In other words, these fields must be
         able to be set such that they are guaranteed to be unique per-
         host.  Typically this requires negotiation of said fields
         between the RSIP host and gateway so that the RSIP gateway can
         guarantee that the fields are unique per-host.

   It is desirable for all demultiplexing fields to occur in well-known
   fixed locations so that an RSIP gateway can mask out and examine the
   appropriate fields on incoming packets.  Demultiplexing fields that
   are encrypted MUST NOT be used for routing.

3.3.  RSIP Protocol Requirements and Recommendations

   RSIP gateways and hosts MUST be able to negotiate IP addresses when
   using RSA-IP, IP address / port tuples when using RSAP-IP, and
   possibly other demultiplexing fields for use in other modes.

   In this section we discuss the requirements and implementation issues
   of an RSIP negotiation protocol.

   For each required demultiplexing field, an RSIP protocol MUST, at the
   very least, allow for:



Borella, et al.               Experimental                      [Page 9]

RFC 3102                    RSIP: Framework                 October 2001


      -  RSIP hosts to request assignments of demultiplexing fields

      -  RSIP gateways to assign demultiplexing fields with an
         associated lease time

      -  RSIP gateways to reclaim assigned demultiplexing fields

   Additionally, it is desirable, though not mandatory, for an RSIP
   protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the type
   of tunnel to be used across the private network.  The protocol SHOULD
   be extensible and facilitate vendor-specific extensions.

   If an RSIP negotiation protocol is implemented at the application
   layer, a choice of transport protocol MUST be made.  RSIP hosts and
   gateways may communicate via TCP or UDP.  TCP support is required in
   all RSIP gateways, while UDP support is optional.  In RSIP hosts,
   TCP, UDP, or both may be supported.  However, once an RSIP host and
   gateway have begun communicating using either TCP or UDP, they MAY
   NOT switch to the other transport protocol.  For RSIP implementations
   and deployments considered in this document, TCP is the recommended
   transport protocol, because TCP is known to be robust across a wide
   range of physical media types and traffic loads.

   It is recommended that all communication between an RSIP host and
   gateway be authenticated.  Authentication, in the form of a message
   hash appended to the end of each RSIP protocol packet, can serve to
   authenticate the RSIP host and gateway to one another, provide
   message integrity, and (with an anti-replay counter) avoid replay
   attacks.  In order for authentication to be supported, each RSIP host
   and the RSIP gateway MUST either share a secret key (distributed, for
   example, by Kerberos) or have a private/public key pair.  In the
   latter case, an entity's public key can be computed over each message
   and a hash function applied to the result to form the message hash.

3.4.  Interaction with DNS

   An RSIP-enabled network has three uses for DNS: (1) public DNS
   services to map its static public IP addresses (i.e., the public
   address of the RSIP gateway) and for lookups of public hosts, (2)
   private DNS services for use only on the private network, and (3)
   dynamic DNS services for RSIP hosts.

   With respect to (1), public DNS information MUST be propagated onto
   the private network.  With respect to (2), private DNS information
   MUST NOT be propagated into the public network.