rfc2356.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,347 行 · 第 1/4 页

Network Working Group                                      G. Montenegro
Request for Comments: 2356                                      V. Gupta
Category: Informational                           Sun Microsystems, Inc.
                                                               June 1998


              Sun's SKIP Firewall Traversal for Mobile IP

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The Mobile IP specification establishes the mechanisms that enable a
   mobile host to maintain and use the same IP address as it changes its
   point of attachment to the network. Mobility implies higher security
   risks than static operation, because the traffic may at times take
   unforeseen network paths with unknown or unpredictable security
   characteristics. The Mobile IP specification makes no provisions for
   securing data traffic.  The mechanisms described in this document
   allow a mobile node out on a public sector of the internet to
   negotiate access past a SKIP firewall, and construct a secure channel
   into its home network.

   In addition to securing traffic, our mechanisms allow a mobile node
   to roam into regions that (1) impose ingress filtering, and (2) use a
   different address space.

Table of Contents

   1. Introduction ...............................................    2
   2. Mobility without a Firewall ................................    4
   3. Restrictions imposed by a Firewall .........................    4
   4. Two Firewall Options: Application relay and IP Security ....    5
   4.1 SOCKS version 5 [4] .......................................    5
   4.2 SKIP [3] ..................................................    6
   5. Agents and Mobile Node Configurations ......................    8
   6. Supporting Mobile IP: Secure Channel Configurations ........    9
   6.1 I: Encryption only Outside of Private Network .............    9
   6.2 II: End-to-End Encryption .................................   10
   6.3 III: End-to-End Encryption, Intermediate Authentication ...   10



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


   6.4 IV: Encryption Inside and Outside .........................   10
   6.5 Choosing a Secure Channel Configuration ...................   11
   7. Mobile IP Registration Procedure with a SKIP Firewall ......   11
   7.1. Registration Request through the Firewall ................   12
   7.1.1. On the Outside (Public) Network ........................   13
   7.1.2. On the Inside (Private) Network ........................   14
   7.2. Registration Reply through the Firewall ..................   14
   7.2.1. On the Inside (Private) Network ........................   15
   7.2.2. On the Outside (Public) Network ........................   15
   7.3. Traversal Extension ......................................   16
   8. Data Transfer ..............................................   18
   8.1. Data Packet From the Mobile Node to a Correspondent Node .   18
   8.2. Data Packet From a Correspondent Node to the Mobile Node .   19
   8.2.1 Within the Inside (Private) Network .....................   20
   8.2.2. On the Outside (Public) Network ........................   21
   9. Security Considerations ....................................   21
   Acknowledgements ..............................................   22
   References ....................................................   22
   Authors' Addresses ............................................   23
   Full Copyright Statement ......................................   24

1. Introduction

   This document specifies what support is required at the firewall, the
   Mobile IP [1] home agent and the Mobile IP mobile node to enable the
   latter to access a private network from the Internet.  For example, a
   company employee could attach his/her laptop to some Internet access
   point by:

      a)   Dialing into a PPP/SLIP account on an Internet service
           provider's network.

      b)   Connecting into a 10Base-T or similar LAN network available
           at, for example, an IETF terminal room, a local university,
           or another company's premises.

   Notice that in these examples, the mobile node's relevant interface
   (PPP or 10Base-T) is configured with an IP address different from
   that which it uses "normally" (i.e. at the office). Furthermore, the
   IP address used is not necessarily a fixed assignment. It may be
   assigned temporarily and dynamically at the beginning of the session
   (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).

   The following discussion assumes a network configuration consisting
   of a private network separated by a firewall from the general
   Internet or public network.  The systems involved are:





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


      Private Network

           A protected network separated from the Internet by hosts
           enforcing access restrictions (firewalls). A private network
           may use a private address space, and its addresses may not
           even be routable by the general internet.

      Public Network

          The Internet at large. Hosts are able to communicate with each
          other throughout the public network without firewall-imposed
          restrictions.

      Mobile Node (MN)

          Its permanent address falls within the range of the private
          network. The user removes the system from its home network,
          and connects it to the Internet at another point.  The
          mechanisms outlined in this discussion render this mobility
          transparent:  the mobile node continues accessing its home
          network and its resources exactly as if it were still within
          it.  Notice that when the mobile node leaves its home
          network, it may migrate both within and outside of the
          private network's boundaries. As defined by Mobile IP [1], a
          mobile node uses a care-of address while roaming.

      Home Agent (HA) for the mobile node

         Serves as a location registry and router as described in the
         Mobile IP IETF draft.

      Foreign Agent (FA)

         Serves as a registration relayer and care of address for the
         mobile node as described in the Mobile IP IETF draft.

      Correspondent Node (CH)

         A system that is exchanging data packets with the mobile
         node.

      Firewall (FW)

         The system (or collection of systems) that enforces access
         control between the private network and the general Internet.
         It may do so by a combination of functions such as application
         gatewaying, packet filtering and cryptographic techniques.




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


   The mechanisms described in this document allow a mobile node out on
   a public sector of the network to negotiate access past a SKIP
   firewall, and construct a secure channel into its home network.  This
   enables it to communicate with correspondent nodes that belong to the
   private network, and, if bi-directional tunnels are used, with
   external hosts that are reachable when the mobile node is at home.
   The mobile node enjoys the same level of connectivity and privacy as
   it does when it is in its home network.

   This document does not address the scenario in which the mobile node
   attempts to access its private network, while within another private
   network.

   Sections 2 and 3 provide an overview of the environment being
   considered and the restrictions it imposes.  Section 4 examines
   firewall technologies. Section 5 discusses the best mode of operation
   of the participating entities from the point of view of Mobile IP.
   Section 6 discusses possible configuration for the secure channel.
   Finally, packet formats are the topic of sections 7 and 8.

2. Mobility without a Firewall

   Suppose the mobile node is roaming throughout the general Internet,
   but its home network is not protected by a firewall. This is
   typically found in academic environment as opposed to corporate
    networks.

   This works as prescribed by Mobile IP [1]. The only proviso is that
   the mobile node would most probably operate with a co-located address
   instead of using a separate foreign agent's care-of address.  This is
   because, at least in the near term, it is far more likely to be able
   to secure a temporary care-of-address than it is to find a foreign
   agent already deployed at the site you are visiting. For example:

   -   Internet Service Provider: pre-assigns customers IP addresses,
       or assigns them out dynamically via PPP's address negotiation.

   -   An IETF terminal room may pre-assign addresses for your use or
       offer DHCP services.

   -   Other locations probably would offer DHCP services.

3. Restrictions imposed by a Firewall

   The firewall imposes restrictions on packets entering or leaving the
   private network. Packets are not allowed through unless they conform
   to a filtering specification, or unless there is a negotiation
   involving some sort of authentication.



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


   Another restriction is imposed by the separation between private
   addresses and general Internet addresses. Strictly speaking, this is
   not imposed by a firewall, but by the characteristics of the private
   network. For example, if a packet destined to an internal address
   originates in the general Internet, it will probably not be
   delivered.  It is not that the firewall drops it. Rather, the
   Internet's routing fabric is unable to process it. This elicits an
   ICMP host unreachable packet sent back to the originating node.

   Because of this, the firewall MUST be explicitly targeted as the
   destination node by outside packets seeking to enter the private
   network. The routing fabric in the general Internet will only see the
   public address of the firewall and route accordingly.  Once the
   packet arrives at the firewall, the real packet destined to a private
   address is recovered.

4. Two Firewall Options: Application relay and IP Security

   Before delving into any details, lets examine two technologies which
   may provide firewall support for mobile nodes:

   -   application relaying or proxying, or

   -   IP Security.

   To understand the implications, let's examine two specific schemes to
   accomplish the above: SOCKS version 5 and SKIP.

4.1 SOCKS version 5 [4]

   There is an effort within the authenticated firewall traversal WG
   (aft) of the IETF to provide a common interface for application
   relays.

   The solution being proposed is a revised specification of the SOCKS
   protocol. Version 5 has been extended to include UDP services as
   well.  The SOCKS solution requires that the mobile node -- or another
   node on its behalf -- establish a TCP session to exchange UDP traffic
   with the FW. It also has to use the SOCKS library to encapsulate the
   traffic meant for the FW. The steps required by a SOCKS solution are:

   -   TCP connection established to port 1080 (1.5 round trips)

   -   version identifier/method selection negotiation (1 round trip)

       -   method-dependent negotiation. For example, the
           Username/Password Authentication [5] requires 1 round trip:




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


           1. client sends a Username/Password request
           2. FW (server) responds

           The GSS-API negotiation requires at least 3 round trips:

           1. client context establishment (at least 1 round trip)
           2. client initial token/server reply (1 round trip)
           3. message protection subnegotiation (at least 1 round trip)

   -   (finally) SOCKS request/reply (1 round trip)

   This is a minimum of 4 (6 with GSS-API) round-trips before the client
   is able to pass data through the FW using the following header:

      +----+------+------+----------+----------+----------+
      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
      +----+------+------+----------+----------+----------+
      | 2  |  1   |  1   | Variable |    2     | Variable |
      +----+------+------+----------+----------+----------+

   Bear in mind that the above must be done each time the mobile
   registers a new care-of address. In addition to this inefficiency,
   this scheme requires that we use UDP to encapsulate IP datagrams.
   There is at least one commercial network that does this, but it is
   not the best solution.

   Furthermore, SOCKS defines how to establish authenticated
   connections, but currently it does not provide a clear solution to
   the problem of encrypting the traffic.

   This header contains the relay information needed by all parties
   involved to reach those not directly reachable.

4.2 SKIP [3]

   Alternatively, traffic from the mobile node to the firewall could be
   encrypted and authenticated using a session-less IP security
   mechanism like SKIP. This obviates the need to set up a session just
   to exchange UDP traffic with the firewall.

   A solution based on SKIP is very attractive in this scenario, as no
   round trip times are incurred before the mobile node and the firewall
   achieve mutual trust: the firewall can start relaying packets for the
   mobile node as soon as it receives the first one.  This, of course,
   implies that SKIP is being used with AH [7] so that authentication
   information is contained in each packet.  Encryption by using ESP [6]
   is also assumed in this scenario, since the Internet at large is
   considered a hostile environment.  An ESP transform that provides