rfc2356.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,347 行 · 第 1/4 页

Montenegro & Gupta           Informational                      [Page 6]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   both authentication and encryption could be used, in which case the
   AH header need not be included.

   The firewall and the mobile node may be previously configured with
   each other's authenticated Diffie-Hellman public components (also
   known as public values).  Alternatively, they could exchange them in
   real-time using any of the mechanisms defined by the SKIP protocol
   (on-line certificate directory service or certificate discovery
   protocol). Home agents and the firewall also MUST have, be able to
   exchange or obtain each other's public components.

   There are other proposals besides SKIP to achieve IP layer security.
   However, they are session-oriented key management solutions, and
   typically imply negotiations spanning several round-trip times before
   cryptographically secure communications are possible.  In this
   respect they raise similar concerns to those outlined previously in
   the discussion on SOCKS-based solutions.  Others have arrived at
   similar conclusions regarding the importance of session-less key
   management for Mobile IP applications [8].

   Another advantage of SKIP is its support for nomadic applications.
   Typically, two hosts communicating via a secure IP layer channel use
   the IP source and destination addresses on incoming packets to arrive
   at the appropriate security association. The SKIP header can easily
   supersede this default mechanism by including the key ID the
   recipient must use to obtain the right certificate.

   The key id is specified by two fields in the SKIP header:

      1) a name space identifier (NSID) to indicate which of the
         possible name spaces is being used, and,

      2) a master key identifier (MKID) that uniquely indicates (within
         the given name space) an id to use in fetching the proper
         certificate.

   As an example, by setting NSID to 1 and MKID to its home address, a
   mobile node tells a receiver "ignore the IP source and use my home
   address instead to look up my public component". Similarly, setting
   NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates.

   In this case, the MKID is set to the MD5 hash of the DH public
   component [10].

   In addition to the NSID/MKID feature, Mobile IP is best supported by
   an appropriate policy at the SKIP firewall in the form of a "nomadic"
   access control list entry. This is an entry which is filtered by key
   ID, instead of by IP source address, as is the usual case. It



Montenegro & Gupta           Informational                      [Page 7]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   translates to "allow access from any IP source address for a given
   NSID/MKID combination".  Furthermore, incoming packets MUST have an
   AH header, so that after properly authenticating them, the firewall
   establishes a "current address" or "dynamic binding" for the nomadic
   host.  The NSID/MKID combination determines which key should be used
   with the nomadic host [9].

   Notice that this supports Mobile IP, because the mobile node always
   initiates contact. Hence, the SKIP firewall has a chance to learn the
   mobile node's "current address" from an incoming packet before it
   attempts to encrypt an outgoing packet.

   However, this precludes the use of simultaneous bindings by a mobile
   node.  At the firewall, the last Registration Request sent by the
   mobile node replaces the association between its permanent address
   and any prior care-of address. In order to support simultaneous
   bindings the firewall must be able to interpret Mobile IP
   registration messages.

   Section 7.2.2 discusses another advantage of making the firewall
   understand Mobile IP packet formats.

   In what follows we assume a SKIP-based solution.

5. Agents and Mobile Node Configurations

   Depending on which address it uses as its tunnel endpoint, the Mobile
   IP protocol specifies two ways in which a mobile node can register a
   mobility binding with its home agent.

      a)   an address advertised for that purpose by the foreign agent

      b)   an address belonging to one of the mobile node's interfaces
           (i.e. operation with a co-located address).

   From the firewall's point of view, the main difference between these
   two cases hinges on which node prepares the outermost encrypting
   encapsulation.  The firewall MUST be able to obtain the Diffie-
   Hellman public component of the node that creates the outermost SKIP
   header in an incoming packet. This is only possible to guarantee in
   case "b", because the mobile node and the firewall both belong to the
   same administrative domain. The problem is even more apparent when
   the mobile node attempts a Registration Request.  Here, the foreign
   agent is not just a relayer, it actually examines the packet sent by
   the mobile node, and modifies its agent services accordingly. In
   short, assuming the current specification of Mobile IP and the
   current lack of trust in the internet at large, only case "b" is
   possible. Case "a" would require an extension (e.g. a "relay"



Montenegro & Gupta           Informational                      [Page 8]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   Registration Request), and modifying code at the home agent, the
   firewall and the foreign agent.

   Assuming that the firewall offers a secure relay service (i.e.
   decapsulation and forwarding of packets), the mobile node can reach
   addresses internal to the private network by encapsulating the
   packets in a SKIP header and directing them to the firewall.

   Therefore, It is simplest to assume that the mobile node operates
   with a co-located address.

6. Supporting Mobile IP: Secure Channel Configurations

   The mobile node participates in two different types of traffic:
   Mobile IP registration protocol and data. For the sake of simplicity,
   the following discussion evaluates different secure channel
   configurations by examining the initial Registration Request sent by
   the mobile node to its home agent.

   Assuming the mobile node operates with a co-located address, it can
   communicate directly with the firewall.  The latter is able to reach
   the home agent in the private network. Also, the firewall MUST be
   able to authenticate the mobile node.

   The following channel configurations assume the mobile node operates
   with a co-located address. The region between the HA (home agent) and
   the FW (firewall) is a private network. The region between the FW and
   the MN (mobile node) is the outside or public network.

6.1 I: Encryption only Outside of Private Network


   HA            FW                        MN
                  <=====================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   The traffic is only encrypted between the mobile node out on the
   general Internet, and the firewall's external interface. This is
   minimum required. It is the most desirable configuration as the more
   expensive encrypted channel is only used where it is necessary: on
   the public network.










Montenegro & Gupta           Informational                      [Page 9]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


6.2 II: End-to-End Encryption

   Another possible configuration extends the encrypted tunnel through
   the firewall:

   HA            FW                        MN
    <===================================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   This limits the firewall to perform a simple packet relay or
   gatewaying function. Even though this could be accomplished by using
   the proper destination NSID in the packet, in practice it is probably
   unrealizable. The reason is that this alternative is probably not
   very popular with computer security personnel, because authentication
   is not carried out by the firewall but by the home agent, and the
   latter's security is potentially much weaker than the former's.

6.3 III: End-to-End Encryption, Intermediate Authentication

   A third alternative is to allow the firewall to be party to the
   security association between the home agent and the mobile node.
   After verifying authentication (AH header), the firewall forwards the
   encrypted packet (ESP hdr) to the home agent.

   HA            FW                        MN
                  <+++++++++++++++++++++>  SKIP authentication
    <===================================>  SKIP encryption
    <----------------------------------->  Registration Request path

   Here, SKIP is used to provide intermediate authentication with end-
   to-end security. Although possible, this option implies that the
   participating entities disclose their pairwise long-term Diffie-
   Hellman shared secret to the intermediate node.

   Whereas Option 2 above is probably not agreeable to security and
   system administration personnel, option 3 is unsavory to the end
   user.

6.4 IV: Encryption Inside and Outside

   HA            FW                        MN
    <============><=====================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   Traffic is encrypted on the public as well as on the private network.
   On the public network, encryption is dictated by a security
   association between the mobile node and the firewall.  On the private
   network, it is dictated by a security association between the home



Montenegro & Gupta           Informational                     [Page 10]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   agent and the firewall.

6.5 Choosing a Secure Channel Configuration

   A potential problem in both options 2 and 3 is that their end-to-end
   channel components assume that the mobile node and the home agent can
   exchange IP traffic directly with each other. This is generally not
   the case, as the Internet routing fabric may not have routes to
   addresses that belong to private networks, and the private routing
   fabric may ignore how to route to public addresses -- or doing so may
   be administratively restricted.  Therefore, it is necessary for
   packets to be addressed directly to the firewall, and indirectly --
   via some tunneling or relaying capability -- to the real destination
   on the other side of the firewall.

   Options 1 and 4 are essentially equivalent. The latter may be
   considered overkill, because it uses encryption even within the
   private network, and this is generally not necessary. What is
   necessary even within the private network is for the home agent to
   add an encapsulation (not necessarily encrypted) so as to direct
   datagrams to the mobile node via the firewall. The type of
   encapsulation used determines the difference between options 1 and 4.
   Whereas option 4 uses SKIP, option 1 uses a cleartext encapsulation
   mechanism.  This is obtainable by, for example, using IP in IP
   encapsulation [2].

   Options 1 and 4 are mostly interchangeable. The difference is, of
   course, that the former does not protect the data from eavesdroppers
   within the private network itself. This may be unacceptable in
   certain cases. Traffic from some departments in a company (for
   example payroll or legal) may need to be encrypted as it traverses
   other sections of the company.

   In the interest of being conservative, in what follows we assume
   option 4 (i.e. traffic is encrypted on the general Internet, as well
   as within the private network.

   Since the firewall is party to the security associations governing
   encryption on both the public and private networks, it is always able
   to inspect the traffic being exchanged by the home agent and the
   mobile node. If this is of any concern, the home agent and mobile
   node could set up a bi-directional tunnel and encrypt it.

7. Mobile IP Registration Procedure with a SKIP Firewall

   When roaming within a private network, a mobile node sends
   Registration Requests directly to its home agent. On the public
   Internet, it MUST encapsulate the original Registration Request in a



Montenegro & Gupta           Informational                     [Page 11]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   SKIP packet destined to the firewall.  The mobile node MUST
   distinguish between "inside" and "outside" addresses. This could be
   accomplished by a set of rules defining the address ranges.
   Nevertheless, actual installations may present serious difficulties
   in defining exactly what is a private address and what is not.

   Direct human input is a very effective method: it may be obvious to
   the user that the current point of attachment is outside its private
   network, and it should be possible to communicate this knowledge to
   the mobile node software.

   The home agent must also distinguish between "inside" and "outside"
   addresses, but lacks the potential benefit of direct user input.
   Accordingly, it should be possible for the mobile node to communicate
   that knowledge to the home agent. To accomplish this we define a
   Traversal Extension to the Registration Requests and Replies.  This
   extension is also useful when traversing multiple firewalls.

   In spite of the above mechanisms, errors in judgement are to be
   expected.  Accordingly, the firewall SHOULD be configured such that
   it will still perform its relaying duties even if they are
   unnecessarily required by a mobile node with an inside care-of
   address.

   Upon arriving at a foreign net and acquiring a care-of address, the
   mobile node must first -- before any data transfer is possible --
   initiate a registration procedure. This consists of an authenticated
   exchange by which the mobile node informs its home agent of its
   current whereabouts (i.e. its current care-of address), and receives
   an acknowledgement. This first step of the protocol is very
   convenient, because the SKIP firewall can use it to dynamically
   configure its packet filter.

   The remainder of this section shows the packet formats used.  Section
   7.1 discusses how a mobile node sends a Registration Request to its
   home agent via the SKIP firewall. Section 7.2 discusses how the home
   agent send the corresponding Registration Reply to the mobile node.
   Section 7.3 defines the Traversal Extension for use with Registration
   Requests and Replies.

7.1. Registration Request through the Firewall

   The mobile node arrives at a foreign net, and using mechanisms
   defined by Mobile IP, discovers it has moved away from home. It
   acquires a local address at the foreign site, and composes a
   Registration Request meant for its home agent.  The mobile node must
   decide whether this packet needs to be processed by SKIP or not.




Montenegro & Gupta           Informational                     [Page 12]