[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Mobile IP                                  John K. Zao, BBN Technologies
Internet Draft                            Matt Condell, BBN Technologies
draft-ietf-mobileip-ipsec-use-00.txt                       November 1997





                       Use of IPSec in Mobile IP




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
   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.''

   Distribution of this memo is unlimited.

   To learn the current status of any Internet-Draft, please check the
   ``1id- abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Copyright (C) The Internet Society (November 1997).  All Rights
   Reserved.

Abstract

   The use of IPSec ESP protocol in the Mobile IP packet redirection
   tunnels will protect the redirected packets against both passive and
   active attacks launched and aid these packets to traverse the firewalls
   surrounding both the home and the foreign subnets visited by the mobile
   nodes.

   This document proposes a scheme to negotiate the use of IPSec ESP on
   selected Mobile IP tunnels and a procedure to establish these tunnels
   with the aid of automatic key and security association management protocol
   such as ISAKMP.







Zao, Condell                                                    [Page 1]


Internet Draft          Use of IPSec in Mobile IP          November 1997


Table of Contents

   1. Introduction........................................................3
   2. Security Requirements of Mobile IP..................................4
   2.1 Security Requirements of Mobile Nodes..............................4
   2.1.1 Connectivity Protection between Mobile Nodes and Home Subnets....4
   2.1.2 Connectivity Protection between Mobile Nodes and Other Subnets...5
   2.2 Security Requirements of Visiting Subnets..........................5
   2.2.1 Protection of Network Resources..................................6
   2.2.2 Protection of Local Traffic......................................6
   3. Use of IPSec on Mobile IP Redirection Tunnels.......................6
   3.1 Operation Principles...............................................6
   3.2 Choice of IPSec Protected Mobile IP Tunnels........................7
   3.2.1 MN-HA Tunnels....................................................9
   3.2.2 HA-FA Tunnels....................................................9
   3.2.3 MN-FA Tunnels...................................................10
   4. Changes to Mobile IP Messages......................................10
   4.1 Extension to Mobility Agent Advertisement.........................10
   4.2 Extension to Mobile IP Registration Request.......................11
   4.3 Mobile IP Registration Reply......................................12
   5. Procedure for MIP-IPSec Tunnel Establishment.......................12
   5.1 Selection of MIP-IPSec Tunnels....................................12
   5.2 Negotiation of Security Associations and Keys.....................13
   5.3 Activation of MIP-IPSec Tunnels...................................13
   6. Format of Encapsulated Packets.....................................14
   7. References.........................................................14
   Disclaimer............................................................15
   Author Information....................................................15






















Zao, Condell                                                    [Page 2]


Internet Draft          Use of IPSec in Mobile IP          November 1997


1. Introduction

   IP mobility support or Mobile IP [rfc2002] enables a mobile node to
   change its attachment point on the Internet while maintaining its IP
   address(es) as well as its network connectivity using these IP
   addresses. The protocol permits mobile internetworking to be done on
   the network layer; however, it also introduces new vulnerabilities to
   the global internet, most notably:

           1. the possibility for an adverse node to spoof the identity of
              a mobile node and redirect the packets destined for the
              mobile node to other network locations,

           2. the risks for potentially hostile nodes (coming from
              different network administrative domains) to launch
              passive/active attacks against one another when they use
              common network resources and services offered by a mobility
              supporting subnet.

   The first type of vulnerability can be surmounted by the strong
   authentication mechanisms built into both basic Mobile IP [rfc2002]
   and route optimized Mobile IP [mip-optim]. With the aid of a public
   key infrastructure [moips], a scaleable countermeasure against the
   spoofing attack can readily be deployed. In contrast, the second type
   of vulnerability was left largely unattended. This Internet Draft
   proposes a scheme to apply IP security protocol [ipsec-arch] onto the
   IP-IP encapsulation used by Mobile IP to redirect IP datagrams to and
   from the mobile nodes. The purpose is to provide authentication and
   confidentiality services to Mobile IP redirection traffics in order
   to protect them against passive and active attacks and to help them
   pass through security gateways.

   The proposed scheme includes

           1. a mechanism for negotiating the use of IPSec protection on
              selected Mobile IP redirection tunnels,
           2. a procedure for establishing these IPSec protected tunnels
              and
           3. the formats of tunneled packets in either full IP-IP or
              minimal IP-IP encapsulations.

   In the next two sections, we will first study the security services
   that are needed to counter the second vulnerability of mobile
   internetworking, and the different IPSec tunnels that can be set up
   in the context of Mobile IP.  Then, we will describe the three parts
   of the proposed scheme in separate sections.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this

Zao, Condell                                                    [Page 3]


Internet Draft          Use of IPSec in Mobile IP          November 1997


   document, are to be interpreted as described in RFC 2119 [rfc2119].

2. Security Requirements of Mobile IP

   The security requirements of mobile internetworking should be
   considered from two perspectives: (1) the expectation of the mobile
   nodes to retain their network services and protect their
   communication when they visit the foreign subnets and (2) the
   expectation of the foreign subnets to protect their network resources
   and local traffic while they are visited by the mobile nodes.

2.1 Security Requirements of Mobile Nodes

   Basically, a mobile node (MN) roaming over the Internet SHOULD enjoy
   safe and persistent IP connectivity as much as this is permitted by
   the policies of its home and visiting subnets. Persistency of IP
   connectivity means that the connections should be handoff correctly
   and quickly so that the MN can maintain its TCP sessions when it
   changes its network attachment point. Safety means traffics to and
   from the MN should enjoy similar level of security (with respect to
   passive and active attacks) as it is on its home subnet.

   The strong authentication of registration messages in both basic and
   route optimized Mobile IP is a crucial step to ensure correct and
   persistent IP connectivity for the MN. Nevertheless, this service
   must be augmented by the other security services (listed below in
   their priorities) as permitted or required by the security policies
   of the home and visiting subnets.

   Notational remarks: In the specification of security services,
   following terms carry special meanings as described below:

           authentication = data origin authentication combined with
                            connectionless message integrity - a typical
                            IPSec service
           optional =       security services to be employed only if it is
                            explicit required by security policy.

2.1.1 Connectivity Protection between Mobile Nodes and Home Subnets

   A MN SHOULD be allowed to have the same IP connectivity with the
   corresponding hosts (CHs) on its home subnet as it is on the home
   subnet. Security gateways guarding the home subnet MUST permit this
   level of connectivity once a policy consisting of some or all of the
   following security requirements is satisfied.  The MN MUST be
   informed of any constraints to its home connectivity before or during
   Mobile IP registration.



Zao, Condell                                                    [Page 4]


Internet Draft          Use of IPSec in Mobile IP          November 1997


           o Authentication of traffic from the mobile node to its home
             subnet enforced by the security gateways protecting the home
             subnet (authentication of incoming traffic)

           o [optional] Confidentiality of traffic between the mobile node
             and the security gateways protecting its home subnet

           o [optional] Confidentiality of traffic between the mobile node
             and the corresponding hosts (end-to-end fine-grain protection)

           o [optional] Authentication of traffic between the mobile node
             and the corresponding hosts (end-to-end fine-grain protection)

2.1.2 Connectivity Protection between Mobile Nodes and Other Subnets

   The MN visiting the subnet SHOULD be allowed to communicate with a
   selected set of corresponding hosts (CHs) that is specified by the
   security policy of the visiting subnet. The permission of MN
   connectivity MUST be qualified by satisfaction of some or all of the
   following security services:

           o [optional] Authentication of traffic from the mobile node to
             the security gateways protecting the visiting subnet
             (authentication of outgoing traffic)

             Note: reverse tunneling must be used if INGRES source
             filtering is employed by the security gateways.

           o [optional] Confidentiality of traffic between the mobile node
             and the corresponding hosts (end-to-end fine-grain protection)

           o [optional] Authentication of traffic between the mobile node
             and the corresponding hosts (end-to-end fine-grain protection)

   The set of connectable CHs MAY be further limited by the security
   policy of MN's home subnet. This indirect application of security
   policy is beyond the scope of this document.

2.2 Security Requirements of Visiting Subnets

   A foreign subnet visited by mobile nodes (MNs) SHOULD employ
   necessary measures (1) to restrict the use of its network resources
   (communication media, printers and servers) by the MNs and (2) to
   protect the traffic flows among local nodes from possible
   passive/active attacks launched by the MNs.





Zao, Condell                                                    [Page 5]


Internet Draft          Use of IPSec in Mobile IP          November 1997


2.2.1 Protection of Network Resources

   The access of the foreign subnet SHOULD be controlled when the MNs
   register through one of its foreign agents (FAs), and the access of
   selected resources (such as servers) MAY be further controlled by
   applying strong authentication and rule/identity-based access control
   to individual MN.

           o Access control of the mobile node to the visiting subnet - if
             possible, the FAs SHOULD verify the identity of visiting MNs
             either directly or indirectly via their home agents (HAs)
             before issuing a care-of address to MN and permitting a
             successful completion of the registration process.

           o [optional] Authentication of traffic between the mobile node
             and the corresponding hosts on the visiting subnet (end-to-end
             authentication)

2.2.2 Protection of Local Traffic

   If the foreign subnet uses a shared medium such as Ethernet for
   communication then a visiting MN may eavesdrop, delete, insert or
   alter packets passing among the local hosts over the medium. Hence,
   encryption and message integrity checks SHOULD be in place to protect
   sensitive communication among the local hosts as well as between the
   local hosts and other MNs.

           o [optional] Confidentiality and data integrity of traffic
             between local hosts on the visiting subnet

3. Use of IPSec on Mobile IP Redirection Tunnels

3.1 Operation Principles

   This Internet Draft proposes a scheme of using IPSec ESP [ipsec-esp]
   protocol to protect selected Mobile IP redirection tunnels. These
   IPSec protected Mobile IP tunnels (MIP_IPSec tunnels) offer message
   confidentiality and authentication (including data origin
   authentication and connectionless integrity) but NOT anti-replay
   services to the IP datagrams to and from the mobile nodes (MNs)
   passing through the mobility agents, i.e. home agents (HAs) and
   foreign agents (FAs). We believe that selective use of these tunnels
   coupled with rule/identity based access control can provide the
   security services described in Sect.2.

   The proposed scheme made certain assumptions on the architecture and
   implementation of this secure Mobile IP system. These assumptions are
   stated below:


Zao, Condell                                                    [Page 6]


Internet Draft          Use of IPSec in Mobile IP          November 1997


           o In order to use the MIP-IPSec tunnels and the mobility agents
             for the best protection of the mobile Internet, both FAs and
             HAs SHOULD function as IPSec supporting security gateways
             capable of performing packet encryption/decryption and packet
             filtering based on strong authentication.

           o On a firewall protected foreign subnet, the FAs SHOULD be the
             firewalls closest to the mobile nodes (MNs). Other firewalls
             on the subnet SHOULD permit the IPSec protected packets to and
             from the FAs to pass through.  Reverse tunneling must be used
             if INGRES source filtering is employed by the firewalls.

           o The HAs SHOULD function as the innermost firewall guarding the
             home subnet.  Similarly, other firewalls on the subnet SHOULD
             permit the IPSec protected packets to and from the HAs to pass
             through.

           o The IPSec implementation is expected to be integrated with the
             Mobile IP implementation. Such an approach allows the use of a
             single IP-IP encapsulation to be used for both IPSec
             protection and Mobile IP packet redirection (except when MN-HA
             IPSec tunnels are used). The approach is also consistent with
             the new roles of FAs and HAs as IPSec supporting security
             gateways. Both the "bump-in-the-stack" (BITS) or the
             "bump-in-the-stack" (BITW) approaches will introduce an extra
             IP encapsulation.

3.2 Choice of IPSec Protected Mobile IP Tunnels

   Figure 1 tabulates all the possible IPSec Mobile IP tunnels existing
   due to different Mobile IP options: collocated car-of-addresses
   [rfc200], reverse tunneling [mip-reverse-tunnel] and route-optimized
   Mobile IP [mip-optim]. The rows of the table list the tunnels roughly
   according to their importance in fulfilling the security requirement
   mentioned in Sect.2. The columns represent different combination of
   Mobile IP options, and the blank entries in the table imply the
   absence of the tunnels underneath specific Mobile IP options.
   Following notations are used in the table:


   C,~C -  denote the use and not use of collocated care-of-address.
   R,~R -  denote the use and not use of reverse tunneling.
   T* -    denotes the cases that an additional IPSec tunnel will be
           encapsulated within the Mobile IP tunnels.
   Te -    denotes the case that requires the use of encapsulated delivery
           from MN and FA in the implementation of Mobile IP reverse
           tunnels.
   (T)-    denotes the cases that duplicate the security functions of other


Zao, Condell                                                    [Page 7]


Internet Draft          Use of IPSec in Mobile IP          November 1997


           tunneling cases.
    X -    denotes the cases that correspond to IPSec protection between
           end hosts, and thus can be implemented using transport mode.
    O -    denotes the cases that exist only in route-optimized Mobile IP.


        |------------------------------------------|
        |          | ~C,~R |  C,~R |  ~C,R |  C,R  |
        |------------------------------------------|
        | HA -> MN |   T*  |   T*  |   T*  |   T*  |
        |------------------------------------------|
        | MN -> HA |   T*  |   T*  |   T*  |   T*  |
        |------------------------------------------|
        | HA -> FA |   T   |  (T)  |   T   |  (T)  |
        |------------------------------------------|
        | FA -> HA |       |       |   T   |  (T)  |
        |------------------------------------------|
        | FA -> MN |   T   |       |   T   |       |
        |------------------------------------------|
        | MN -> FA |       |       |   Te  |       |
        |------------------------------------------|
        | CH -> MN |   X   |   X   |   X   |   X   |
        |------------------------------------------|
        | MN -> CH |   X   |   X   |   X   |   X   |
        |------------------------------------------|
        | CH -> FA |   O   |   O   |   O   |   O   |
        |------------------------------------------|
        | FA -> CH |   O   |   O   |   O   |   O   |
        |------------------------------------------|
        | CH -> HA |       |       |       |       |
        |------------------------------------------|
        | HA -> CH |       |       |       |       |
        |------------------------------------------|
        Figure 1. Choices of IPSec Protected Mobile IP Tunnels



   The MIP-IPSec tunnels running between MN-HA, HA-FA, FA-MN are the
   essential ones for fulfilling the security requirements. They will be
   examined individually in the following paragraphs. In addition, the
   end-to-end IPSec protection between MNs and CHs can be used in
   combination with the IPSec tunnels.  Notice that Mobile IP tunnels do
   NOT run between CHs and HAs, and the tunnels running between CHs and
   FAs exist only in route-optimized Mobile IP. This is because
   corresponding hosts may be completely ignorant of Mobile IP, and may
   not know of the existence of FAs and HAs.




Zao, Condell                                                    [Page 8]


Internet Draft          Use of IPSec in Mobile IP          November 1997


3.2.1 MN-HA Tunnels

   The MN-HA MIP-IPSec tunnels can be used to provide data-origin
   authentication plus connectionless integrity and data
   confidentiality.  They are most useful in providing a secure
   communication path between a MN and its home subnet as described in
   [ipsec-arch, case 4] as shown in the following diagram.

            ==============================
            |                            |
            |                         ---|--------------------------
            |                         |  |                         |
           H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
                                      |           Intranet)        |
                                      ------------------------------
                                            admin. boundary


   The data-origin authentication and connectionless integrity can
   counter active attack while data confidentiality can frustrate
   eavesdropping. By using the tunnels in both directions, a MN SHOULD
   be allowed to enjoy same connectivity as it has at home.

   The MN-HA tunnels are, however, more expensive to establish -- since
   they are NOT one of the Mobile IP redirection tunnels, they must be
   established separate- ly with the use of an additional IP header.

3.2.2 HA-FA Tunnels

   The MIP-IPSec tunnel going from a HA to a FA (and from a FA to a HA
   if reverse tunnel and FA Care-of Address are used) can be implemented
   by simply adding IPSec protection to the existing Mobile IP tunnels.

   The tunnels can also be used to support data-origin authentication
   plus connectionless integrity and data confidentiality. They
   establish virtual private network (VPN) connections between the home
   subnet of the MN and the foreign subnet currently visited by the MN
   as shown in the following diagram.

                        =========================
                        |                       |
     -------------------|----                ---|---------------------
     |                  |   |                |  |                    |
     | H1 -- (Local -- SG1* |-- (Internet) --| SG2* -- (Local --- H2 |
     |       Intranet)      |                |         Intranet)     |
     ------------------------                -------------------------
         admin. boundary                             admin. boundary



Zao, Condell                                                    [Page 9]


Internet Draft          Use of IPSec in Mobile IP          November 1997


The main uses of the FA-HA tunnels are (1) to frustrate passive and
active attacks from the open Internet, and (2) to traverse firewalls
between FAs and HAs. Such a tunnel MAY allow the MN to access its home
subnet only if it is coupled with strong authentication of the MN by the
FA and system security of the FA.

3.2.3 MN-FA Tunnels

   The MN-FA MIP-IPSec tunnels can be used in two ways if no link-layer
   protection has already provided the services:

           1. data confidentiality for MN over the foreign network and
           2. data origin authentication of MN-FA exchange.

   The MN-FA tunnels exist only if MN chooses to use an FA Care-of
   Address and they must be built by re-encapsulating the IP datagrams.
   Hence, these tunnels are ex- pensive to use and should be replaced by
   MN-CH end-to-end IPSec protection or MN-HA IPSec tunnels whenever
   possible.

4. Changes to Mobile IP Messages

   In order for the mobile nodes (MNs) and the mobility agents (FAs and
   HAs) to agree on the selection of MIP-IPSec tunnels, the FA and the
   MN SHOULD use the following two extensions (added to the mobility
   agent advertisement and the registration request) for proposing their
   choices.  Upon reception of the registration request, the HA SHOULD
   decide weather to accept and reject the proposal based on its
   security policy and then return its decision using the return codes
   in the registration reply.  Such a selection process is deemed
   necessary owing to the difficulty of formulating static IPSec
   policies to handle the migration of mobile nodes. Because FAs and HAs
   SHOULD only serve the MNs if they complete the registration process,
   it is necessary to devise a mechanism to generate the IPSec policies
   for the selected tunnels and insert them into the security policy
   database (SPD) at the end of the process.

4.1 Extension to Mobility Agent Advertisement

   An FA IPSec Tunnel Extension is added to the mobility agent
   advertisement message, which conforms to the format of an ICMP router
   advertisement. The purpose of the extension is to carry FA's choice
   of MIP-IPSec tunnels. The type- length-value (TLV) format of the
   extension is shown in Figure 2.






Zao, Condell                                                   [Page 10]


Internet Draft          Use of IPSec in Mobile IP          November 1997


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Type      |    Length     |F|R| reserved  |F|R| reserved  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                         |<- MN Tunnel ->|<- HA Tunnel ->|

                   Figure 2. FA IPSec Tunnel Extension

         Type     [TBD]

         Length   2 bytes

         F        IPSec Protection for Forward Tunnels ( HA->FA, FA->MN )

         R        IPSec Protection for Reverse Tunnels ( FA->HA, MN->FA )

         reserved IGNORED upon reception; MUST be set to ZERO during
                  transmission

4.2 Extension to Mobile IP Registration Request

   An MN IPSec Tunnel Extension is added to the registration request
   message.  This extension indicates the choices of MIP-IPSec tunnels
   made by MN based on its own policy and its knowledge of FA's choices.
   The extension carries SIX flags, each when SET indicates the use of
   IPSec on a possible tunnel. The extension format is shown in Figure
   3. To simplify processing, the flags in the FA IPSec Tunnel
   Extensions remain in the same positions.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Type      |    Length     |F|R|   |F|R|   |F|R| reserved  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                          FA      HA      HA
                                         |<- MN Tunnel ->|<- FA Tunnel ->|

                    Figure 3. MN IPSec Tunnel Extension

         Type     [TBD]

         Length   2 bytes

         F        IPSec Protection for Forward Tunnels
                  ( HA->FA, FA->MN, HA->MN )



Zao, Condell                                                   [Page 11]


Internet Draft          Use of IPSec in Mobile IP          November 1997


         R        IPSec Protection for Reverse Tunnels
                  ( FA->HA, MN->FA, MN->HA )

         reserved IGNORED upon reception; MUST be set to ZERO
                  during transmission

4.3 Mobile IP Registration Reply

   FOUR error codes are added to the registration reply for conveying
   possible failures of the tunnel selection process.

   Service denial by HA:

           Values          Semantics
           ------          ----------------------------
           [TBD]           Tunnel Selection Conflict
           [TBD]           Tunnel Selection Unsupported

   Service denial by FA:

           Values          Semantics
           ------          ----------------------------
           [TBD]           Tunnel Selection Conflict
           [TBD]           Tunnel Selection Unsupported

5. Procedure for MIP-IPSec Tunnel Establishment

   The process of establishing the MIP-IPSec tunnels can be divided in
   three steps: (1) tunnel selection, (2) security association
   negotiation and (3) tunnel activation. Among them, tunnel selection
   happens concurrently with Mobile IP registration and tunnel
   activation occurs also in ordinary Mobile IP tunneling.  The
   insertion of security association (SA) negotiation is a new step, and
   it introduces a new complexity to the process: owing to the possible
   failure of SA negotiation, a MIP-IPSec tunnel MAY need to be
   dismantled even after a success- ful Mobile IP registration. The case
   will be discussed in a following section.

5.1 Selection of MIP-IPSec Tunnels

   Like Mobile IP registration, the tunnel selection process begins with
   mobility agent advertisement. FAs SHOULD announce their IPSec
   tunneling requirements in the FA IPSec tunnel extension after
   consulting their security policies. The advertisement is usually NOT
   authenticated due to the lack of key management prior to this
   process.

   After receiving the advertisement message, an MN MAY response by


Zao, Condell                                                   [Page 12]


Internet Draft          Use of IPSec in Mobile IP          November 1997


   sending an MN registration request to the FA, and MAY attach an MN
   IPSec tunnel extension to the request. The extension MUST carry the
   choice of MIP-IPSec tunnels made by the MN based on its own security
   policy and FA's choice conveyed in the advertisement. The
   registration request including the extension MUST be authenticated to
   the HA of the MN, and MAY also be authenticated to the FA if keys
   have been exchanged between the MN and the FA.

   Upon receiving the registration request, FA MUST compare its own
   choices of IPSec tunnel with the corresponding choices of the MN, and
   return a "Tunnel Selection Conflict" error in an FA registration
   reply to MN if a mismatch is found. Otherwise, FA SHOULD forward the
   registration request to the HA.

   When the HA receives the registration request, it MUST check the
   IPSec tunnel choices against its own security policies (beside of
   making other Mobile IP registration decisions). HA MUST return a
   "Tunnel Selection Unsupported" error in an HA registration reply if
   the choices are incompatible to its policies.

   Any error code in the registration replies MUST cause the failure of
   the registration process. A successful registration process will
   cause appropriate entries to be inserted in the IPSec SPD in MN, FA
   and HA as a preparation for subsequent SA negotiations.

5.2 Negotiation of Security Associations and Keys

   The negotiation process is analogous to that of an ordinary IPSec
   tunnel esta- blishment. A successful Mobile IP registration promises
   only IP connectivity between the mobile node and the relevant
   mobility agents, but leaves the IP traffic without any protection. SA
   negotiations SHOULD then be conducted through these unprotected IP
   tunnels using protocols like ISAKMP [isakmp]. A failure of the
   negotiations SHOULD imply a failure of establishing the corresponding
   MIP- IPSec tunnel. Thus, it MUST cause the generation of proper error
   events and the prohibition of any secure communication via the
   corresponding tunnel. Whether the Mobile IP tunnel should be
   dismantled SHOULD be decided according to the Mobile IP policies
   enforced by the end points.

5.3 Activation of MIP-IPSec Tunnels

   Since the existence of Mobile IP tunnels do NOT necessarily imply the
   existence of corresponding MIP-IPSec tunnels, the IPSec tunneling
   services MUST only be activated after the successful negotiation of
   necessary security associations.  Before such activation, only
   limited types of traffic, e.g. key management exchanges, are allowed
   to use these tunnels. General traffic can only use the tunnels when


Zao, Condell                                                   [Page 13]


Internet Draft          Use of IPSec in Mobile IP          November 1997


   the required IPSec services are in place.

6. Format of Encapsulated Packets

   In the cases that IPSec tunneling services are added to the existing
   Mobile IP tunnels, both tunnels SHOULD be implemented using a common
   IP-IP encapsulation [Sect.6.1]. In the only case of MN-HA tunneling,
   an MN-HA IPSec tunnel MUST be embedded into outer Mobile IP (HA-FA,
   FA-MN) tunnels. Hence, an extra IP header will be inserted along with
   ESP header between the Mobile IP encapsulation and the original IP
   header.

   The IP encapsulation can be implemented using either full IP-IP
   encapsulation [full-ipip] or minimal IP-IP encapsulation [mini-ipip].
   The only exception is that the extra IP header that implements the
   MN-HA IPSec tunnel can NOT be in the form of minimal encapsulation.

7. References

   [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Level," RFC-2119, March 1997.

   [rfc2002] C. Perkins (ed.) "IP Mobility Support." RFC2002, proposed
             standard. IETF Mobile IP Working Group, Oct. 96.

   [mip-optim]D.B. Johnson, C. Perkins. "Route Optimization in MIP."
             <draft-ietf-mobileip-optim-03>, IETF Mobile IP Working
             Group, Nov. 95.

   [mip-tunnel-reverse]G. Montenegro. "Reverse tunneling for Mobile IP".
             <draft-ietf-mobileip-tunnel-reverse-02>, IETF Mobile IP
             Working Group, Mar. 97.


   [isakmp]  D. Maughan, M. Schertler, M. Schneider, J. Turner.
             "Internet Security Association & Key Management Protocol
             (ISAKMP)" <draft-ietf-ipsec-isakmp-07>, IPSec Working
             Group, Feb. 97.


   [ipsec-arch]S. Kent, R. Atkinson.  "Security Architecture for the
             Internet Protocol." <draft-ietf-ipsec-ipsec-arch-??>, IETF
             Network Working Group, Aug. 95.


   [moips]   J. Zao, S. Kent, J. Gahm, G. Troxel, M. Condell, P.
             Helinek, N.  Yuan, I. Castineyra. "A Public-Key Based
             Secure Mobile IP".  MobiCom97.  Sep. 97.


Zao, Condell                                                   [Page 14]


Internet Draft          Use of IPSec in Mobile IP          November 1997


Disclaimer

   The views and specification here are those of the authors and are not
   necessarily those of their employers.  The authors and their
   employers specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

Author Information

   Dr. John K. Zao
   BBN Technologies
   70 Fawcett Street
   Cambridge, MA  02138
   USA
   E-mail: jzao@bbn.com
   Telephone: +1 (617) 873-2438

   Matt Condell
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138
   USA
   E-mail: mcondell@bbn.com
   Telephone: +1 (617) 873-6203


   Copyright (C) The Internet Society (November 1997).  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


Zao, Condell                                                   [Page 15]


Internet Draft          Use of IPSec in Mobile IP          November 1997


   "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
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.













































Zao, Condell                                                   [Page 16]