[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

     Network Working Group                                       Jari Arkko
     INTERNET-DRAFT                                                Ericsson
     <draft-arkko-mipv6-bu-security-01.txt>                   November 2001


                   Issues in Protecting MIPv6 Binding Updates


1.   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 docu¡
     ments  of  the  Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute  work¡
     ing documents as Internet-Drafts.

     Internet-Drafts  are draft documents valid for a maximum of six months
     and may be updated, replaced, or made obsolete 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   may    be    found    at
     http://www.ietf.org/ietf/1id-abstracts.txt

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

     The distribution of this memo is unlimited.  It is  filed  as  <draft-
     arkko-mipv6-by-security-00.txt>,  and   expires  May 20, 2001.  Please
     send comments to the author or to Mobile IP working group.

2.   Abstract

     The Mobile IP working group is  currently  searching  for  a  security
     solution  that  enables  semi-secure, weak authentication between IPv6
     Mobile Nodes and Correspondent Nodes in the the global Internet.  Sub¡
     sequent  Binding  Updates  messages  will  then  be  cryptographically
     integrity protected to prevent abuse of the mechanisms for route opti¡
     mization.   This  memo  assumes  a  suitable  authentication mechanism
     exists, and discusses various alternatives on how the BUs can be  pro¡
     tected.  We  note that there are multiple alternatives. In particular,
     the solution space is more fine grained than "Use  IPsec  for   every¡
     thing" and  "Don't  Use IPsec At All". Fair amount of detail is neces¡
     sary to explain how the solutions work, whether  any  standard  exten¡
     sions  are  needed,  what kind of APIs are needed between stack parts,
     what the implications are to piggybacking, how the solutions fit situ¡
     ations where strong authentication is also a requirement, and so on.

3.   Contents


       1.          Status of this Memo..................................1
       2.          Abstract.............................................1
       3.          Contents.............................................1



     J. Arkko                   Expires May 2002                   [Page 1]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


       4.          Introduction.........................................2
       5.          Main Requirements....................................3
       6.          Solutions............................................4
         6.1.      Application Specific Protection......................6
         6.2.      Existing IPsec AH with a New Next Header Value.......6
         6.3.      IPsec AH with Policy Extensions......................8
         6.4.      Application Specific Protection with Optional IPsec..10
       7.          Piggybacking Binding Updates.........................11
         7.1.      Implications to Protecting BUs with IPsec............12
         7.2.      Implications to IPsec Protection of Other Traffic....12
         7.3.      Bandwidth Implications...............................12
         7.4.      QoS Implications.....................................14
         7.5.      Other Implications...................................15
         7.6.      Other Solutions to the Piggybacking Problem..........16
       8.          Comparison of Solutions..............................16
         8.1.      Requirements Fulfillment.............................17
         8.2.      Header Overhead......................................18
         8.3.      Computational Overhead...............................19
         8.4.      Memory and State Requirements........................20
         8.5.      IANA Requirements....................................21
         8.6.      Standardization Work.................................22
         8.7.      Evolution of Authentication Protocols................22
         8.8.      Error Situations.....................................23
         8.9.      Optimizations for Busy Servers.......................23
         8.10.     Address Ownership....................................24
         8.11.     Implementation Aspects...............................24
       9.          Conclusions..........................................25
       10.         Further Work.........................................27
       11.         Acknowledgements.....................................28
       12.         References...........................................28
       13.         Revision History.....................................29

4.   Introduction

     The  Mobile  IP  working  group  is currently searching for a security
     solution that enables weak authentication between  IPv6  Mobile  Nodes
     (MNs)  and  a Correspondent Nodes (CNs) in the the global Internet. It
     is necessary to accept less than perfect security in  this  situation,
     because  strong  authentication between previously unknown peers would
     require a global Public Key Infrastructure (PKI). With  current  state
     of the art, this is neither possible nor desirable.

     The  purpose  of  the  weak authentication mechanism is to establish a
     Binding Security Association (BSA) between the MN and the CN  for  the
     secure  exchange  of  Binding  Updates (BUs). The main content of such
     BSAs are the keying material derived as a part of  the  authentication
     mechanism.  BUs  will be cryptographically integrity protected to pre¡
     vent abuse of the mechanisms for route optimization. The  main  reason
     for  creating  such  BSAs  is  actually optimization: after a possibly
     multi-round authentication protocol has been run, keying material  can
     be created to enable subsequent protection using the BSA, avoiding the
     need to rerun the authentication.





     J. Arkko                   Expires May 2002                   [Page 2]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     This memo assumes a suitable authentication mechanism exists, and dis¡
     cusses  various alternatives on how the BUs can be protected. Further¡
     more, we discuss how strong authentication can optionally be  used  in
     those  situations  where suitable trust infrastructure exists, such as
     inside corporate networks.

     Even if we discuss the relationship of the BU protection to  authenti¡
     cation  and  key  agreement,  this  memo relies only on the ability of
     these mechanisms to produce BSAs. Technical details of  how  they  are
     performed  are  outside  the  scope of this memo and must be discussed
     elsewhere.

     The motivation for writing this memo is to provide a concrete  set  of
     proposals for BU integrity protection, in one document together with a
     comparison of their pros and cons.

     The memo is outlined as follows. In Chapter 5, we discuss a very  high
     level  set  of  requirements,  without going to the details on exactly
     what weak authentication means as this is already discussed in [2]. In
     Chapter  6,  we introduce the alternative ways on how we think the BUs
     can be protected. Chapter 7 is devoted to the discussion of how piggy¡
     backing  affects  the  solutions.  Chapter 8 compares the alternatives
     against each other in terms of their security, efficiency, use of pre¡
     cious protocol numbers, requirements for new standardization work, and
     other criteria. Chapter 9 concludes with some of the main findings.

     In this memo we assume that the authentication mechanisms indeed  pro¡
     duce BSAs and the optimization to not rerun authentication is a neces¡
     sary one. (It isn't certain that this is the case, however. The matter
     is discussed elsewhere [22, 23].)

5.   Main Requirements

     The main requirements that are relevant from the point of view of this
     memo are the following:

     >> R1: It MUST be possible to integrity protect BUs against in-transit
     modifications or forgery.

     >>  R2: It MUST be possible to protect the BUs against replay attacks.
     (This is a requirement, though binding updates  themselves  contain  a
     mechanism against replay attacks.)

     >> R3: It MUST NOT be possible for nodes to use their own BSAs to send
     BUs on the behalf of other nodes.

     >> R4: It SHOULD be possible to derive BSAs for BU  integrity  protec¡
     tion from weak authentication.  (While this draft assumes the BSAs are
     derived, we note that this is an optimization and therefore in general
     we do not require BSAs.)

     >>  R5: It MUST be possible to derive BSAs for BU integrity protection
     from strong  authentication.   (By  'strong  authentication'  we  mean
     mainly IKE, but other possibilities can also be considered.)



     J. Arkko                   Expires May 2002                   [Page 3]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     >>  R6: It SHOULD be possible to use alternative integrity algorithms.
     All implementations MUST implement one designated algorithm for inter¡
     operability reasons. This is a corollary of requirement 4 in [2]. Note
     that this requirement speaks of the actual BU protection.  Authentica¡
     tion part needs also several mechanisms, as indicated by R4 and R5.

     Interestingly  enough,  this requirement set looks very different from
     that defined in [2]. This is mainly because in this memo we only  con¡
     sider  the  BU  protection,  and  do not go to the details of what the
     requirements for the weak authentication are. However,  we  note  that
     the possible inclusion of requirements R2 and R5 to [2] should be con¡
     sidered. It seems clear that R2 is a requirement, while R5 is  perhaps
     controversial, and should be discussed.

6.   Solutions

     In this chapter we discuss various solutions for the protection of the
     BUs. We note that there are multiple alternatives. In particular,  the
     solution  space  is  more fine grained than "Use IPsec for everything"
     and "Don't Use IPsec At All". Furthermore, all the solutions  have  to
     be  described  in  a  fair  amount of detail in order to make it clear
     exactly how they can work, and how they can work  together  with  both
     weak  and  strong  authentication,  and the evolution of protocols for
     strong authentication.

     The alternative solutions that will be discussed are listed below:

     - Application specific protection,  i.e.  the  use  of  the  mechanism
     defined in the -14 version of the Mobile IPv6 draft [1].

     -  Existing  IPsec  AH  with a new next header value for BUs.  In this
     alternative we can use the current versions of IPsec AH and  IP  Secu¡
     rity Architecture since BUs are not piggybacked to other packets.

     -  IPsec  AH with policy extensions. Certain extensions to the current
     requirements for security policy  data  bases  and  SA  selectors  are
     needed  in  order to protect BUs that are embedded in the Destinations
     Options header of packets possibly containing also other payloads.

     - Application specific protection with optional, additional IPsec pro¡
     tection. For instance, we use the -14 mechanism and the weak authenti¡
     cation in all situations, but apply also IPsec and IKE within a corpo¡
     rate network.

     These   four   alternatives  correspond  the  different  philosophical
     approaches to the problem. The first alternative treats the Mobile  IP
     security  problem  as  a separate issue that should be solved indepen¡
     dently of other problems, and at exactly the manner that suits  Mobile
     IP  the  best  way.  The second alternative tries to maximize reuse of
     existing solutions, while possibly making compromises on what kind  of
     functionality  can  be  offered.   The  third  alternative also reuses
     existing solutions, but does not settle for compromises. Finally,  the
     fourth  approach  looks upon the specific Mobile IP solutions and gen¡
     eral corporate network security solutions  as  complementary  to  each



     J. Arkko                   Expires May 2002                   [Page 4]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     other.

     It  doesn't  seem possible to treat the above list completely indepen¡
     dently from the way the authentication is handled. For instance, it is
     possible  to use strong authentication but there are several different
     ways how we can provide it. Therefore, the list below shows what  kind
     of authentication mechanisms can be combined with the above solutions:

     - Nothing. It should still be possible to use unsecured BUs.

     - The sole use of a new weak authentication protocol.

     - The use of a new protocol capable of both weak and strong  authenti¡
     cation.

     - The use of a new weak authentication protocol and an existing strong
     authentication protocol. If an existing protocol is  used  unmodified,
     this  limits  the  BU  protection  mechanism to those supported by the
     authentication protocol already. In practice, only IPsec AH  could  be
     used for BU protection if the authentication protocol is kept as is.

     -  The use of a new weak authentication protocol and an enhancement of
     an existing strong authentication protocol.  This would allow both the
     use  of IPsec AH and the application specific mechanism defined in the
     -14 draft [1].

     Assuming multiple authentication methods can be used  (e.g.   nothing,
     weak,  and  strong), how does one know which one to choose? Currently,
     there doesn't seem to be any other answer to this than  configuration.
     On  a  particular network, for instance, all machines could be config¡
     ured to use only strong authentication.  Making the selection  becomes
     harder  if multiple authentication methods need to be enabled simulta¡
     neously. For instance, strong authentication is always required within
     a  corporate  network  but to the rest of the world we allow also weak
     authentication. Typically, VPN-like mechanisms for representing  poli¡
     cies  on  IP  addresses and networks can be used here. In any case, we
     take the position here that some form of security MUST be  applied  to
     all BUs, and it is not permissible to turn off the BU security.

     In some recent discussions the use of very simple authentication tech¡
     niques such as return routability has been brought up. While this memo
     does  not  address that type of solutions we indicate that IPsec-based
     SAs are fundamentally limited to provide security only through  shared
     secrets.  This  is  the  current  assumption also in the -14 draft. It
     appears possible to use simpler types of security  as  well,  such  as
     some  methods in Erik Nordmark's proposal [22]. If these simpler meth¡
     ods are found suitable, then neither the current  -14  nor  the  IPsec
     models  are  appropriate. But as discussed earlier, the shared secrets
     are used as an optimization, and it remains to be seen  if  acceptable
     solutions  can  be  found without this optimization. This is discussed
     more in depth in [22, 23].






     J. Arkko                   Expires May 2002                   [Page 5]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


6.1. Application Specific Protection

     In this mechanism, the Binding Update and its acknowledgement  options
     are  kept in the Destination Options header, and contain an SPI and an
     integrity check vector. (The options always contain a sequence  number
     as  well.)  All  operations  on these security related fields are per¡
     formed within the Mobile IP implementation itself, and no effects out¡
     side  the  Destination Options header can be seen.  Further details on
     this mechanism are described [1].

     No specific user actions are needed in order to configure this  mecha¡
     nism.  All BUs and their acknowledgements will be required protection,
     by the software taking care of the mobile IP  functionality.  In  this
     mechanism,  it  would also be possible to allow both secured and unse¡
     cured BUs during the deployment phase  of  secure  Mobile  IPv6.  This
     would  also  have  to  be  configured, either as an always allowed but
     optional security, or on a per network basis. However, we do not  rec¡
     ommend  this  and  propose that if this method is selected, it is made
     mandatory to use in all nodes employing Route Optimization.

     In the case that strong authentication is also desired  for  BUs,  the
     configuration becomes much harder. There are no key distribution mech¡
     anisms currently designed to key -14 BSAs.

     As the BUs are kept in the Destination Option header, no next protocol
     numbers  are  consumed by this mechanism, but an option number is con¡
     sumed. It is possible to piggyback the BUs on  regular  TCP  or  other
     payload traffic, and there are no effects to upper layers.

     If  this  mechanism is used together with traffic flows that for other
     reasons use IPsec, the rules governing the addition and removal of the
     Destination  Options  must be constructed so that the Mobile IPv6 pro¡
     cessing offers the same packet for the IPsec AH ICV calculations. This
     doesn't seem to be a problem.

     The  authentication  and key agreement protocol can be run independent
     of the BUs, or even within the BU packets.

     It is not possible to use  existing  strong  authentication  protocols
     unchanged in this solution.

6.2. Existing IPsec AH with a New Next Header Value

     In  this  approach, the Binding Updates and their acknowledgements are
     sent in packets separate from actual payload traffic, with a new  pro¡
     tocol  number (or a UDP port). IPsec SAs are used for the BSAs.  AH is
     used to protect the BUs, though the  SAs  are  created  using  a  weak
     authentication protocol and not IKE.

     The  policy  database  for IPsec is set up so that packets destined to
     the particular host with the BU protocol number require the use  of  a
     particular  SA.  This SA is the one that was created for BU traffic to
     that host.  Otherwise the packets are dropped. The weak authentication
     protocol  creates  the  SAs when the Mobile IPv6 signaling needs them.



     J. Arkko                   Expires May 2002                   [Page 6]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     Like all other IP and higher layer processing, IPsec  policy  matching
     is  performed on the used home addresses rather than Care-of-Addresses
     (see section 10.1 in [1]). This means that a particular IPsec  SA  can
     be  used even if the MN moves and changes its CoA, and that a particu¡
     lar SPD entry can only be used by the right host. In this case the  so
     called  address  ownership  problem [10] does not exist, since the SPD
     entries and the SAs have been created only through the  authentication
     protocol, and the SPD entries require the use of a specific address in
     a specific SA.

     A typical SPD would contain entries such as the ones below:

       1. mn1 to here with proto=BU => use SA1
       2. here to mn1 with proto=BU => use SA2
       3. mn2 to here with proto=BU => use SA3
       4. here to mn2 with proto=BU => use SA4
       5. proto=BU => drop

     In this example the CN at address "here" has had a  contact  with  two
     mobile  nodes at addresses "mn1" and "mn2". Two pairs of SAs have been
     created to protect the signaling to these, SA1/SA2 and SA3/SA4. All BU
     traffic  to these nodes is protected using these SAs, and any other BU
     traffic is simply dropped. (Note that as a mobile node sees a need  to
     send  BUs  to  another node, it first runs the authentication protocol
     which will establish these rules.)

     The organization of the SPD presented above is just one possible  one.
     In  this case an API is required to dynamically update the policy data
     base from the Mobile IP implementation.  In an another type of organi¡
     zation,  a  single BU-related general policy rule would be sufficient,
     and the correct SAs would be picked with selectors. IPsec has the con¡
     cept  of  "selectors",  which  are tied to each SA. The purpose of the
     selectors is to specify which SA to use within a set of SAs. A typical
     VPN policy, for instance, might say that all traffic must be encrypted
     with IPsec. However, since a host may communicate with  several  other
     hosts,  one  SA  pair  is  not  sufficient to under this general rule.
     Instead, a number of SA pairs are established, and the  selectors  are
     used to determine which particular SA to use for a particular destina¡
     tion address. These checks are applied to packets in both  directions.
     In  the  case  of protecting BUs in this alternative, the selectors of
     each SA would be set to the particular addresses used in the  communi¡
     cations.   In  the  example the selectors would correspond to checking
     that the e.g. packets sent through SA1 had "mn1" and "here"  as  their
     source  and  destination  addresses,  respectively.  This organization
     would require the IPsec implementation to understand a new type  of  a
     policy entry, one that should not initiate IKE negotiations even if no
     SA exists.

     The user's configuration set-up is  interesting.  One  alternative  in
     doing  this  is to set up a specific Mobile IPv6 policy entry, but the
     policies could also be set automatically from the  Mobile  IPv6  soft¡
     ware, which would probably be easier in terms of configuration. In any
     case, the user can turn on or off the protection, and could also do so
     on  a  per-network  or  host  basis.  However, we propose that this be



     J. Arkko                   Expires May 2002                   [Page 7]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     disallowed, and require Mobile IPv6 software to  ensure  that  it  the
     policies  are  set up so that they only allow either the use of IPsec,
     or force the BU packets to be dropped. Also, it would not be  easy  to
     allow security as an optional service since standard IPsec policy data
     bases always either demand or disallow security.

     A single protocol number is needed for the BUs  in  this  alternative.
     The same number could be used for both BUs and their acknowledgements.
     No option numbers are needed.  Given that the IPsec policy  data  base
     is  set  up to use the protocol number as a decision factor, it is not
     possible to send the BUs and payload data in the same packets.

     In this alternative, IPsec can be used also  for  other  purposes,  to
     protect  the  payload traffic. The policy database must be constructed
     so that the BU protection rules and other rules do not overlap.

     All authentication mechanisms are possible in this solution, including
     the  use  of existing protocols such as IKE [4]. It isn't necessary to
     modify the existing protocols. The Mobile IP implementation  can  look
     at  the  SPD when it needs to create a new SA.  If a regular IKE-based
     rule already exists for the particular other host, the  SA  establish¡
     ment  is  left to IKE. If not, the weak authentication protocol is run
     and an SA and the corresponding SPD entry are created.

6.3. IPsec AH with Policy Extensions

     In this approach, the current  model  used  for  representing  BUs  is
     retained,  but IPsec policy rules are extended beyond the requirements
     of the current standard. The extension is necessary in order for it to
     be  possible to represent rules about BUs in Destination Options. Cur¡
     rently, IPsec standard requires only the possibility to construct pol¡
     icy  rules  based  on addresses, protocols (IPv6 next header numbers),
     and port numbers.

     The policy database for IPsec is set up in a  manner  similar  to  the
     previous  alternative,  except  that  the policies look at the options
     part, not the protocol numbers. That is, one of the SAs that have been
     created  for  the  protection of the BUs must be used if the BU option
     appears in the packet, or otherwise the packets are dropped. The  weak
     authentication protocol creates the SAs when the Mobile IPv6 signaling
     needs them. The concept of "selectors" also  needs  to  be  used.  The
     selectors  are  tied to each SA, and their purpose is to specify which
     particular SA to use within a set of SAs. The selectors would  be  set
     to  the particular addresses used in the communications. This prevents
     a node from sending other node's binding updates inside  its  own  SA.
     Again, home addresses are used the policy matching.

     The  user's configuration set-up in this alternative is similar to the
     previous alternative: the  configuration  could  be  done  through  an
     explicit  Mobile IPv6 entry in the policy table, or automatically from
     the Mobile IPv6 software. The latter would probably be easier in terms
     of  configuration.  Again,  we suggest the Mobile IPv6 software or the
     IPsec user interfaces don't allow accepting cleartext BUs.  Otherwise,
     various different security policies can be set either globally or on a



     J. Arkko                   Expires May 2002                   [Page 8]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     per-network or host basis. It would not be easy to allow  security  as
     an optional service.

     As the BUs are kept in the Destination Option header, no next protocol
     numbers are consumed by this mechanism, but an option number  is  con¡
     sumed.  It  is  possible  to piggyback the BUs on regular TCP or other
     payload traffic, and there are no effects to upper layers.

     IPsec can be used also for other  purposes,  to  protect  the  payload
     traffic. However, this requires the construction of the policy entries
     in a manner that takes  in  account  the  possibility  that  a  packet
     matches  both  the BU rules, and some other rules, such as in the case
     of important TCP traffic that also happens to carry a piggybacked  BU.
     Unlike  in  the case of separate protocol number, these is no easy way
     to avoid such overlap in this case. However, given the new,  extended,
     policy  rule specifications, these situations must be taken care of in
     the policies themselves, i.e. the user will dictate what kind of secu¡
     rity will apply to e.g. BUs, TCP, and BUs piggybacked to TCP

     A typical SPD would contain entries such as the ones below:

       1. neta to here with proto=TCP => IPsec with IKE
       2. neta to here with proto=* and BU option => IPsec with weak authentication
       3. here to neta with proto=TCP => IPsec with IKE
       4. here to neta with proto=* and BU option => IPsec with weak authentication
       5. * to here with proto=* and BU option => IPsec with weak authentication
       6. here to * with proto=* and BU option => IPsec with weak authentication
       7. * to here with proto=* => pass
       8. here to * with proto=* => pass

     In  this example the CN at address "here" allows traffic with the net¡
     work "neta". Traffic that has TCP is protected with the  normal  IPsec
     means, regardless of whether there are possible Binding Updates (rules
     1 and 3). Traffic that has only the BU option but no TCP, is protected
     using  weak  authentication (rules 2 4). For all other addresses, only
     the packets containing BU options are protected, regardless  of  upper
     layer protocol numbers (rules 5 and 6).

     As the CN communicates with MNs, the weak authentication protocol cre¡
     ates new entries under the given policy rule sets (2, 4, 5, and  6  in
     our  example).  The  SAs have selectors that ensure the correct SA was
     used. The selectors would correspond to checking  that  the  e.g.   an
     address "hosta1" within "neta" uses its own SA, not someone else's SA.
     This means that the selectors for the SAs are more specific  than  the
     policy  entries,  as  is  described  in  4.4.1  option  a in [11]. For
     instance, assuming SAs have been created with hosts hosta1 and  hosta2
     within  neta,  the  following  SA entries and selectors would be found
     under the policy rules 2 and 4:

       2: policy = neta to here with proto=* and BU option
          SA1: hosta1 to here with proto=* and BU option
          SA3: hosta2 to here with proto=* and BU option
       4: policy = here to neta with proto=* and BU option
          SA2: here to hosta1 with proto=* and BU option



     J. Arkko                   Expires May 2002                   [Page 9]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


          SA4: here to hosta2 with proto=* and BU option

     The Mobile IP implementation  requires  an  access  to  the  IPsec  SA
     database  in  this alternative. The SPD can stay static, but the IPsec
     implementation must understand that it may not e.g.  start IKE negoti¡
     ations based on the "weak authentication" policy rules.

6.4. Application Specific Protection with Optional IPsec

     In  this  alternative, two different protection mechanisms are applied
     independently of each other. For instance, we use  the  -14  mechanism
     and  the weak authentication in all situations, but apply additionally
     also IPsec and IKE where a suitable PKI exists, such  as  in  corpora¡
     tions.   This  may  lead to the use of two security headers protecting
     partially the same packet. On the other hand the independence  of  the
     Mobile IP and IP security solutions relieves the need to extend policy
     rules, or to open APIs between the two stack parts.

     The Binding Update and its acknowledgement options  are  kept  in  the
     Destination  Options header, and contain an SPI and an integrity check
     vector. All operations on these security related fields are  performed
     within the Mobile IP implementation itself, and no effects outside the
     Destination Options header can be seen. Further details on this mecha¡
     nism are described [1]. An independent protection is provided by stan¡
     dard IPsec/IKE means for the traffic specified in the SPD.  Given that
     standard SPD granularity is used, the IPsec protection does not neces¡
     sarily apply only to the BUs, but also to  other  traffic.  This  may,
     however,  be  in  line  with  security requirements as we will discuss
     later.

     There are two aspects to the user configuration in  this  alternative.
     There  are no specific actions needed to configure Mobile IP security.
     The IPsec security policies are in this alternative set up in a normal
     manner,  by  the user's manual configuration (the automatic procedures
     for creating SPD entries outlined in section 5.2 do not apply).

     An example of a configuration is presented below. In this  example  BU
     protection  is  on  everywhere,  and  all  traffic to and from network
     "neta" shall be protected with IPsec:

       MIP configuration:
         (empty, always on)

       IPsec SPD configuration:
         1. neta to here => use IPsec/IKE
         2. here to neta => use IPsec/IKE
         3. * => pass

     As the BUs are kept in the Destination Option header, no next protocol
     numbers  are  consumed by this mechanism, but an option number is con¡
     sumed.

     It is possible to piggyback the BUs on regular TCP  or  other  payload
     traffic,  and there are no effects to upper layers. However, the IPsec



     J. Arkko                   Expires May 2002                  [Page 10]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     policies can't be expressed in enough detail to protect just the  BUs.

     This solution allows the granularity of the weak BU protection and the
     strong protection to be different.  That is,  it  isn't  necessary  to
     protect  solely  the BU packets. Typically, an organization that has a
     PKI and likes to protect their BU traffic would typically  run  strong
     security  on all of their traffic (possibly excluding some flows, such
     as those to port 80). This means that while BU protection  is  applied
     only packets that contain the BUs, IPsec would typically be applied on
     all traffic. IKE or other IPsec authentication protocols would be  run
     in  order  to  create SAs upon the first contact of two peers, and all
     traffic - including weakly protected BUs - would run inside the  IPsec
     tunnels between the peers.

     In  a variant of this approach, the application layer protection could
     be turned off where IPsec is  available,  or  turned  off  when  IPsec
     becomes capable of protecting piggybacked BUs.

7.   Piggybacking Binding Updates

     The Binging Updates are currently specified to be sent within the IPv6
     Destination Options. As has been described above, there are some limi¡
     tations  on  how  IPsec  policies can be used to protect such options.
     There has been a discussion in the Working Group about the  possibili¡
     ties  to  rethink  the position of the Binding Updates in the packets.
     Placed in its own separate  packet,  the  protection  of  the  Binding
     Updates  would  be easier with IPsec. However, in doing so we lose the
     ability to piggyback Binding Updates on payload packets, which may  be
     an  important  function  in reducing packet counts, contention for the
     physical medium, and so on. Also, if not allowed from the beginning it
     may  be  hard  to add the piggybacking functionality later. Yet piggy¡
     backing causes also problems, and could be seen as extra complexity.

     In order to understand the consequences of removing piggybacking, this
     chapter  studies  the  consequences  of either allowing or disallowing
     piggybacking. The following aspects will be studied:

     - Effects to the use of IPsec in the context of Binding Updates.

     - Effects to the use of IPsec of other traffic.

     - Effects to the amount of bandwidth consumed.

     - Effects to header compression on low-bandwidth links.

     - Effects to QoS mechanisms.

     It should also be noted that the term "piggybacking" can be understood
     in  different ways. Here, we use it to mean end-to-end BU piggybacking
     to payload packets. Other possible meanings include link layer  piggy¡
     backing,  and end-to-end generic piggybacking for not just BUs but all
     IPv6 packets.





     J. Arkko                   Expires May 2002                  [Page 11]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


7.1. Implications to Protecting BUs with IPsec

     The use of piggybacking precludes the use of IPsec with current  stan¡
     dards, as the granularity of the policy mechanisms does not allow sep¡
     arating packets that have important options.

     As described in section 5.3, it is possible extend  these  mechanisms.
     (Implementors  have  also  reported  on the mailing list [19, 20] that
     they have made local (not visible on the wire) modifications to  their
     implementations to allow piggybacking with IPsec. This is however pos¡
     sible only if you have access to the IPsec implementation.)

7.2. Implications to IPsec Protection of Other Traffic

     Note that the effects of piggybacking are more related to  the  trans¡
     port  of two different items within one packet, than to the storage of
     one item within the options header. The current policy mechanisms  are
     unable  to  handle  multiple items with potentially differing security
     needs.  Therefore, substituting options for a new intermediate  header
     type  doesn't  by  itself solve the policy problem. If piggybacking is
     needed, then policy conditions relating both to BUs  and  the  payload
     traffic  will  be necessary, allowing users to dictate how the various
     combinations of  these  will  be  protected.   If  piggybacking  isn't
     needed, a slightly simpler policy mechanism suffices, as it would only
     be necessary to match individual messages, not combinations of BUs and
     other  traffic.   (Current  IPsec policy mechanisms would suffice if a
     separate protocol number (or port) was used for BUs; IPsec  extensions
     would  be  needed  if  they  still  were  contained in the Destination
     Options.)

     Does piggybacking have other effects to protecting the  payload  traf¡
     fic,  assuming  either  application layer protection or enhanced IPsec
     policy processing handles the BU protection?  The enhanced policy pro¡
     cessing  certainly  allows  the users to pick their own security poli¡
     cies. However, it is still possible that fundamental  conflicts  occur
     in  how  the  user wants the traffic to be protected. For instance, in
     order to protect the BU part, AH would be needed but the payload traf¡
     fic could need confidentiality protection through ESP. It appears that
     these conflicts can be handled by providing both AH  and  ESP  protec¡
     tion, as allowed by the current specifications [11].

     Finally,  it  has also been suggested [9] that the use of piggybacking
     could be selected by the sender of the BU, based on the existing secu¡
     rity  policies.  The sending node would select piggybacking only if no
     security headers are needed. Another idea taking this a bit further is
     that the the piggybacking could only be allowed if the security policy
     towards the other node requires all protocols to use the same SA  [3].

7.3. Bandwidth Implications

     The  number of BUs sent by a MN varies, and in case it talks with sev¡
     eral CNs, each movement may generate similarly several  BUs.  In  this
     sense the amount of space consumed by the BUs does matter.




     J. Arkko                   Expires May 2002                  [Page 12]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     Sending  the  BUs as separate packets causes an immediate need to send
     an extra packet which implies a certain number  of  extra  transferred
     bits.  On  LAN  networks  the  effect of this is an extra 40 byte IPv6
     header. This is probably not noticeable, unless a central server keeps
     a  very  large number of binding cache entries. In order for the extra
     overhead to reach a substantial fraction of the traffic of  a  central
     server,  the  server must receive much binding update traffic compared
     to  the  amount  of  traffic  resulting  from  its  transactions.  For
     instance,  consider  a  server  that on average receives a BU on every
     tenth request and has request size of 100 and  response  size  of  200
     bytes.  The  overhead cause by extra BU messages for this server would
     be ((40+40)/10) / (100+300) = 2.7%.

     However, the most pressing issues in bandwidth conservation are proba¡
     bly not in larger servers or LAN traffic but in hosts operating behind
     cellular or other highly constrained interfaces. There, an  additional
     40  bytes is a significant cost even if not sent often.  But the esti¡
     mation of the difference between piggybacked and separated  packet  is
     harder  since  on  these interfaces advanced header compression mecha¡
     nisms and other techniques are typically used. As an example, we  have
     considered  the ROHC header compression schemes [12].  Its adoption in
     various cellular standards as a compression  mechanism  justifies  its
     use as an example.

     The  techniques  in  ROHC  allow collapsing the IP and transport layer
     headers when they don't change or change predictably between  packets.
     Interestingly, ROHC is capable of dealing with options as a difference
     that can be  sent  without  requiring  the  full  IPv6  header  to  be
     repeated.  This  means  that  when  ROHC is used, piggybacked BUs only
     cause extra bandwidth usage that is close to proportional of the  size
     of the BU headers.

     When  a  separate packet is sent with a new protocol number, the first
     time ROHC needs to send a full IPv6 header as well as the  BU  itself.
     Subsequent  Binding  Updates can be compressed, and the payload stream
     continues to be compressed independently of the new BU stream.  There¡
     fore,  in  the  case  of ROHC, piggybacking is in the long run roughly
     equivalent to the non-piggybacked case. There is a difference for  the
     first packet, of roughly 40 bytes.

     At  present,  ROHC  has  special support for RTP, UDP, and some of the
     basic IPv6 extension headers. It compresses other extension headers in
     a  generic  way.   ROHC  will be able to compress the BUs partially or
     completely away regardless of whether they are in a separate header or
     inside the Destination Options [21].

     While not directly relevant for the piggybacking discussion, we should
     note that ROHC supports both AH  and  ESP  [12,  section  5.8].  Small
     changes  in these and other IPv6 extension headers can be sent as dif¡
     ferences.

     The DOCSIS PHS is another example of a compression mechanism. It  uses
     bit  masks  to signal identical fields, and would appear to be able to
     work well both with at least non-piggybacked  traffic,  provided  that



     J. Arkko                   Expires May 2002                  [Page 13]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     separate contexts again would be held for BUs and other streams.

     DOCSIS  also allowed more than one frame to be sent on a single trans¡
     mission opportunity. This allows non-piggybacked traffic  to  use  the
     same  opportunity,  not  changing the number of sent bits but reducing
     delay even if the BUs are sent separately.

     The use of header compression for Binding Updates is also affected  by
     movements.  Unless  there is a context transfer between base stations,
     compression state of the BU sender is lost in any case at the time the
     BU  is  sent. BU receivers will still be able to use compression, how¡
     ever.

7.4. QoS Implications

     When Mobile IP signaling and payload traffic are combined in the  same
     packets  Quality-of-Service (QoS) conflicts may occur, as the user may
     have wanted to assign different priorities to them.  The relevance  of
     this  can be questioned, as the growth of the packets is only marginal
     and the packet could reasonably be expected to be tagged with the flow
     label  of  the payload regardless of the additional options. Also, the
     sender has the possibility to send packets separately if the QoS poli¡
     cies  are  in  conflict. However, such separation is only possible for
     the sender and not for any of the routers in between. (The routers are
     in some architectures responsible for the QoS tasks.)

     A more serious QoS problem appears in cellular networks where specific
     channels have been allocated for the host to  send  and  receive  e.g.
     multimedia  streams. Any TDM-like slot allocation scheme may need such
     QoS reservations.  Such channels have been calculated to  be  able  to
     carry exactly the stream (even taking in account ROHC and other header
     compression techniques) but nothing else. An additional signaling pay¡
     load  appended  to the stream would essentially force the packet to be
     dropped, or routed through best effort channels. In the case  of  con¡
     versational  services,  the  latter alternative would also in practice
     mean losing the whole packet, because it would be unlikely  to  arrive
     in time to be useful.

     As  far  as  an individual cellular terminal is concerned, it can make
     smart decisions about when to piggyback and when to not. However, this
     option  does not necessarily exist for the other end of the communica¡
     tions; a MN carelessly sending a piggybacked BU along a stream to  its
     correspondent cellular host might cause the BU information and a frac¡
     tion of the stream to be lost.

     Specifically reserved tight channels are a fact of life.  However,  it
     is perhaps fair to note that making IP run inside them is already dif¡
     ficult even without piggybacked  BUs.  Header  and  other  compression
     mechanisms  produce  variable  length  results, and the in the case of
     Mobile IP the channel reservation may have to take in account not just
     the  BUs,  but also other options.  What is different, however, in the
     case of BUs is first of all their size - at least two  dozen  bytes  -
     which  may  make it hard for them to fit the slack, and it is undesir¡
     able to reserve so much extra space.  Secondly,  BUs  are  dynamically



     J. Arkko                   Expires May 2002                  [Page 14]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     changing while e.g. Home Address options are other similar headers are
     static. Static headers in general are always compressed away,  and  in
     any case predicting their size is easier.

     Piggybacking  may  also  interact with resource reservations at the IP
     layer, such as those performed by RSVP.

7.5. Other Implications

     It has been said that piggybacking is used today also as a facility to
     send the BUs at an appropriate time, conveniently along other traffic.
     The intent is to not send binding updates until it is proven that fur¡
     ther  traffic  to the Correspondent Node exist.  On the other hand, it
     appears that this convenient mechanism can't be used all of the  time,
     given  that  it  only  works  in one direction, and does not allow for
     optimized routing of packets sent by the CN.  For this reason  typical
     implementations  wait  a while and send the BU in any case if no other
     traffic has appeared [19].

     We also note that in both piggybacked and separate packet solutions we
     can  achieve  the  same goals. A BU should be sent at a suitable time,
     specified in the standards or left to the optimization logic of  vari¡
     ous  implementations.  With  piggybacking, a BU can be attached to the
     packet that is destined to the CN. Without piggybacking,  the  appear¡
     ance  of  a  packet  destined  to  the CN would trigger the sending of
     another packet along it. Similar functionality  exists  today  on  all
     IPv6  stacks  to  send  address  resolution messages and other control
     traffic, so it seems that it on most stacks it should be  possible  to
     generate  new packets based upon seeing traffic to a particular desti¡
     nation.

     One difference between the piggybacked and the separate  packet  solu¡
     tions  is  that in the latter we can not guarantee that the BU arrives
     at the CN before the payload packet. The BUs are  used  in  the  route
     optimization  functionality  -  which  is  optional - and decided on a
     case-by-case anyway by implementations. Therefore, the payload traffic
     will get to the other end and back regardless of the BUs.  If the sep¡
     arate BUs are delayed behind the payload packets, it is possible  that
     the  payload response comes through an unoptimized route. However, let
     us assume that the first two packets along a router are  going  to  be
     reordered.   In  the  piggybacked solution this means that the regular
     packet gets to the destination first, following the  packet  that  has
     the  piggybacked  BU.  In this situation one packet needs to be routed
     through the home. In the non-piggybacked solution the BU and the first
     payload  packet  get  reordered,  and again one the result is that one
     packet needs to be routed through  the  home.   Assuming  packets  are
     routed  through  the  home  works best, however, only when the MN - CN
     first contact each other and don't  have  an  existing  Binding  Cache
     Entry.  Where  an  entry  exists,  and the MN is now moving to another
     location, it becomes essential to be able to inform the CN as soon  as
     possible,  as otherwise packets may get lost to the previous location.

     As has been discussed earlier, it is also possible that  the  addition
     of  the  BUs  may  cause the packets to be routed differently, and may



     J. Arkko                   Expires May 2002                  [Page 15]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     already imply delayed reception. On the other the BU packets  -  small
     packets - may easily get different treatment than the regular packets,
     making it slightly more likely that a reordering will occur.  In  con¡
     clusion,  there  does  not seem to be a fundamental difference in this
     regard.

     Firewalls and other similar devices should be able to  process  piggy¡
     backed  packets,  even if they have BU options in them. If they do not
     let such traffic through they will also not let regular Mobile IP Home
     Address  options through, blocking all traffic. If the BUs are sent in
     separate packets, the firewalls have to have rules to allow this traf¡
     fic in.

     A  similar situation to the BU problem appears in the case of RSVP and
     the Router Alert options [17]. In this case IPsec was not used and the
     option was kept as an option.

     As  has been indicated elsewhere [23], it may be necessary to run some
     of the weak  authentication  protocols  as  a  separate  protocol/port
     rather  than  as a Destination Option, in order be able to pass suffi¡
     ciently long public key values. This does not have an  effect  to  the
     piggybacking  as such, because where such long public keys are needed,
     the BSA-based approach will be likely necessary and therefore the weak
     authentication and actual BUs can run in different protocols anyway.

7.6. Other Solutions to the Piggybacking Problem

     It  has  also been suggested that a more general purpose multi-payload
     IPv6 mechanism could be developed [13]. This would allow adding piggy¡
     backing  later in as an option, and could tackle the IPsec problems in
     a general way and without delaying the Mobile IPv6 standardization.

     One worry around this solution is that the Mobile IPv6  implementation
     may  not  have  enough  capabilities to direct the merging of packets.
     For instance, if the merging is implemented  as  a  general  IP  layer
     function,  it is not guaranteed that BUs get merged unless two packets
     are actually seen simultaneously. As the first packet may  already  be
     partially  out  from  an  interface, it is not clear that the function
     will see these packets early enough. However,  it  appears  that  this
     problem can be solved by having the Mobile IP code perform the merging
     when it detects a need to send a BU.

     A more serious problem in this solution comes from the partial deploy¡
     ment,  which  obviously can't be avoided as such multi-payload schemes
     are not a part of current IPv6. How does a node know when the receiver
     supports  this  feature  and  when  not?  It  may  be  possible to use
     responses, errors, or the lack  of  these  as  an  indication  of  the
     receiver's support. However, it is not clear what kind of implications
     this has for the additional messaging, start-up times, and so on.

8.   Comparison of Solutions

     The following criteria are used in evaluating the pros and cons of the
     presented solutions:



     J. Arkko                   Expires May 2002                  [Page 16]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     -  Requirements fulfillment. For instance, do the solutions allow both
     weak and strong authentication?

     - The header overhead of the solution, and the number of extra packets
     required.

     -  The  computational  overhead of the solution. (Note that public key
     cryptography, Diffie-Hellman, and other overhead related to  authenti¡
     cation is not under discussion here. It is assumed that the user orga¡
     nizations select between the heavier strong  authentication  protocols
     and  the lighter weak authentication protocols. The comparison of par¡
     ticular authentication protocols such as BAKE [6], SUCV [7] and others
     [18] also isn't the subject of this memo.)

     - The memory and state requirements of the solution.

     -  The necessity to allocate Destination Option or Next Header numbers
     from IANA.

     - The required standardization work.

     - Are the mechanisms future proof, as the current  strong  authentica¡
     tion  protocols  evolve  to new ones (which is expected to happen with
     the Son-of-IKE effort).

     - Ability to handle error situations.

     - Ability to optimize behaviour for busy servers.

     - Ability to ensure that the right BSAs are used for the right BUs.

     - Implementation aspects.

8.1. Requirements Fulfillment

     Like the other alternatives, the application  specific  solution  ful¡
     fills the requirements for integrity protection and replay protection,
     the former through the -14 mechanisms and the latter  through  the  BU
     replay counters.

     This alternative also allows the use of a new weak authentication pro¡
     tocol, or a new protocol capable of both weak and  strong  authentica¡
     tion.   The  use  of  an existing strong authentication protocol isn't
     directly possible, an enhancement of both the protocol  standards  and
     the  implementation  would be necessary. The enhancement necessary for
     e.g. IKE [4] would involve adding a new protocol along the side of  AH
     and   ESP   with  possible  other parameters such as algorithm identi¡
     fiers.  This would be an extension of the current IPsec DoI [5].

     The -14 mechanisms can satisfy the requirement to be able to use  dif¡
     ferent  algorithms.  However, at the moment [1] does not define even a
     single algorithm, let alone alternatives.





     J. Arkko                   Expires May 2002                  [Page 17]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     The IPsec based alternatives fulfill the  requirements  for  integrity
     protection  and  replay  protection,  both through AH mechanisms. Note
     that an additional layer of replay protection exists at  the  BU  mes¡
     sages.  It  isn't  possible  to  remove the fields related to this, as
     IPsec provides only replay protection but not sequenced delivery.  For
     the  Mobile  IP route optimization to work, sequenced delivery is also
     needed.

     Existing IPsec AH can use both weak and strong  authentication  proto¡
     cols.  There is no need to modify the strong authentication protocols,
     or the IPsec stack in order to make this possible.  However,  a  local
     API  must  exist  between the new weak authentication protocol and the
     IPsec implementation in order to set up suitable  policy  entries  and
     SAs.

     IPsec  AH  with  extended  policy  rules  allows the use of a new weak
     authentication protocol, or a new protocol capable of  both  weak  and
     strong  authentication.   The use of an existing strong authentication
     protocol isn't directly possible, an enhancement of both the  protocol
     standards  and the implementation would be necessary. The use of a new
     weak authentication protocol and an enhancement of an existing  strong
     authentication  protocol.  The  enhancement necessary for e.g. IKE [4]
     would involve an extension of the client identifiers  to  support  the
     extended policies capable of differentiating IPv6 Destination Options.
     It is not possible to use  existing  strong  authentication  protocols
     unchanged in this solution.

     All  IPsec AH based solutions satisfy the requirement on being able to
     use different algorithms. A  set  of  standard,  mandatory  algorithms
     exists, as well as many optional ones.

     The use of both application specific and IPsec mechanisms fulfills the
     requirements for integrity protection and replay protection.

     Various combinations of authentication protocols could be used in this
     alternative, but one particular combination seems most suited. Namely,
     a new weak authentication protocol could be used  to  key  exclusively
     the  application  specific  protection  of BUs, and an optional strong
     authentication protocol would build SAs that use IPsec around them.

8.2. Header Overhead

     In the application specific solution, the integrity protection related
     parts  in  the  BUs  contain  the authentication data length, SPI, and
     authentication data fields.  The length  of  the  last  field  is  not
     given, but assuming a typical 96 bit field is used, the total overhead
     from this is 17 bytes.

     IPsec AH-based solutions add the SPI, sequence number, next  protocol,
     and MAC fields.  The total number of additional bytes is 24.

     For  the  combined  use of both application specific and AH mechanisms
     there is a fixed cost of 17 bytes in all BU  messages.  An  additional
     cost  of  24  bytes  is  applied  to  those messages that use also the



     J. Arkko                   Expires May 2002                  [Page 18]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     IPsec/IKE-based security. Therefore, a total of 41 bytes overhead  may
     be reached in the worst case.

     The number of packets in the application specific, extended IPsec, and
     combined alternatives are the same as piggybacking can be employed. In
     the  use  of existing IPsec AH there are N additional packets, where N
     is the number of BUs and their acknowledgements sent.

8.3. Computational Overhead

     The application specific scheme runs a cryptographic hash over  speci¡
     fied  fields,  typically 62 bytes assuming there are no BU suboptions.
     The nature of the cryptographic hash hasn't been specified, but we can
     safely  assume it is similar to mechanisms used elsewhere such as HMAC
     MD5.

     The number of bytes used in the input to the hash function has signif¡
     icance, though the hash functions typically have some amount of static
     cost so that the computational overhead is not linear with respect  to
     the  number of input bytes. In one implementation of HMAC MD5, a four-
     fold increase in the size of the packet increased the amount  of  time
     spent by 33% (for small packets).

     The  same  implementation  achieved  speeds  of  around  60 Mbit/s, or
     100,000 MACs/s for an input of size 62 bytes, on  a  Pentium  600  MHz
     machine.  Increasing  the  size  fourfold changed these numbers to 170
     Mbit/s and 75,000 MACs/s. Similar numbers are also available for other
     implementations  [14].  These numbers indicate that a relatively large
     number of BUs can be treated with typical computer systems; likely far
     more than is required for anything else except the busiest servers. On
     a smaller devices such as handheld  cellular  devices,  the  available
     power is much smaller but so is also the number of BUs that need to be
     treated; it is hard to imagine why a device with a constrained  inter¡
     face towards the Internet would have to process even 1 BU/s.

     IPsec  uses  also  standard  cryptographic  hash  functions,  which we
     assumed would also be used in the application specific protection.  In
     contrast  to the BU suboption, however, the hash is run over the whole
     packet. Assuming the size of a BU protocol running directly on top  of
     IP  would  be  roughly the same as in a BU option, the total number of
     input bytes would be 40 from the IPv6 header, 18 from the Home Address
     option, 24 from AH, plus 10 from the BU protocol, i.e. 92.

     These  numbers  imply that the pure cryptographic operations necessary
     in this alternative are roughly equivalent to those needed for BU pro¡
     tection  in  the  application  specific manner.  In addition there are
     IPsec-related tasks such as  policy  matching  and  header  processing
     which are harder to quantify. Implementations also differ much in this
     respect, as some may be using sequential searches  and  others  trees.
     One  good  software-based IPsec implementation reports the speed of 65
     Mbit/s with AH HMAC_MD5 in  transport  mode,  on  a  Pentium  800  Mhz
     machine,  and  82  MBit/s when policies were being checked but none of
     the packets needed security.  The  unsecured  IP  performance  was  85
     Mbit/s [14] on the same machine.



     J. Arkko                   Expires May 2002                  [Page 19]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     In  any case, these numbers again indicate sufficient capacity to deal
     with BUs under most normal circumstances, possibly with the  exception
     of  the  busiest servers. A crucial factor is the amount of BU traffic
     vs. other traffic.  Let us assume 10 KB regular traffic interrupted by
     a 0.1 KB BU, and a system that would handle 10 Mbit/s BUs. Even if the
     reference used above didn't describe the  packet  sizes  used  in  the
     test,  it seems safe to assume that a single CPU would be able to han¡
     dle this load.  But under these assumptions, the system would also  be
     handling  1  GBit/s  other  traffic.  If  there's only 1 KB (one large
     packet) of traffic between the BUs, then  this  number  would  be  100
     MBit/s.

     Application specific protection would allow easier treatment of policy
     processing and SA searches, as the Binding Cache Entries could be used
     to store the right BSA (or a small number of them, in case overlapping
     BSAs are allowed). This means that it would not be necessary to create
     an  efficient  data structure to make a fast search, as is the case in
     IPsec.

     The computational overhead for extended IPsec is similar  to  that  of
     existing  IPsec,  except  that  now  also  the payload contents may be
     included in the  hash  calculations.  Assuming  the  average  original
     packet  size  of, say, 300 bytes, this makes the real packet size with
     all options and AH to be 352. This is also the input to the hash func¡
     tion.

     Given  our  earlier measurement data, it doesn't seem that the size of
     the packets matters as much as might be expected. Some increase in CPU
     demands will be seen, however.

     In  the  combined use of application specific and IPsec solutions, the
     computational overhead at the minimum is the same as in  the  applica¡
     tion  specific  protection, i.e. running a hash over 62 bytes. In case
     IPsec/IKE-based security is used in addition, then an additional  sec¡
     ond  hash  needs to be calculated. Assuming again the 300 byte average
     original packet size, this amounts to running a hash over 369 bytes.

     Again, the size of the input to the hash operations does not  seem  to
     have  significant  importance.  However,  the  number of operations is
     important and in this situation there are two. The two hashes are cal¡
     culated, however, only within the protected network communications.

     All IPsec-based approaches typically require calculating the MACs once
     the whole packet has been completed and formed. In  contrast,  the  BU
     suboption method allows doing this somewhat earlier as the BU is being
     created. This may offer the advantage of being  able  to  perform  the
     cryptographic  operation  at the time of the movement, not at the time
     we are waiting to get some payload traffic to the peer. This may  also
     be useful for a retransmission of a BU.

8.4. Memory and State Requirements

     In  the  application  specific  solution,  a security association data
     structure is needed for every BSA established to protect the BUs.  The



     J. Arkko                   Expires May 2002                  [Page 20]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     current assumption is that the BSAs are unidirectional, but unlike the
     IPsec solution they could also be bidirectional  and  thereby  halving
     the  memory requirements.  Note that there may in any case be multiple
     concurrent BSAs per each MN in order to  allow  for  smooth  rekeying.
     Each  BSA must contain information about the used integrity key (typi¡
     cally at least 20 bytes), the SPI (4 bytes), lifetime (4 bytes), algo¡
     rithm  (under 1 byte) and an implementation dependent amount of admin¡
     istrative information, such as  pointers  to  Binding  Cache  entries,
     statistics, and other relevant information.

     Security  association  data  structures  are needed also for the IPsec
     SAs. IPsec SAs are a bit more general-purpose  than  application  spe¡
     cific SAs, including for instance encryption keys, selectors, lifetime
     and statistics information, and other similar data. Typical  implemen¡
     tations  use  memory  in  the order of, say, 400 bytes for each SA. An
     implementation optimized for memory  usage  could  cut  this  down  to
     around  170 bytes, most of which is spent on the IPv6 addresses needed
     for the destination and selector addresses.

     In addition to the SA information,  the  IPsec  implementations  (may)
     need  to  add policy entries related to each specific host. These need
     both memory, and execution time for each packet.  Typical  implementa¡
     tions  would  perhaps use a similar amount of space for a policy entry
     as they do for an SA. On a MIP-specific solution, we didn't need  this
     as the policy is hardcoded to the processing of the BUs.

     There  isn't much information available on how large number of SAs and
     policy  entries  typical  implementations  support.  Special  hardware
     devices  can  support  tens  of  thousands of simultaneous connections
     [15]. A central question is the support for a large number of  SAs  in
     typical  server  OS implementations. Smart implementations can provide
     logarithmic-time processing of security rules and SA  databases  [16],
     but some implementations may be built more around VPN access scenarios
     (small number of SAs) rather than end-to-end security towards multiple
     directions.

     There  may  be optimizations available for devices that do not want to
     support IPsec in general and only want to support it  for  BU  protec¡
     tion. In this case it is possible to eliminate execution time overhead
     for other packets, and to use the Binding Cache entries  and  BSAs  as
     the sole packet matching mechanism.

     The  memory  and  state requirements for combined application specific
     and IPsec alternative is (roughly) a sum of the requirements  for  the
     two mechanisms.

8.5. IANA Requirements

     The application specific solution requires a Destination Option number
     to be allocated for the BUs.

     The existing IPsec AH solution requires a new IPv6 next header value -
     a more valuable resource - to be allocated.




     J. Arkko                   Expires May 2002                  [Page 21]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     With  an  extension to the IPsec policies, only the Destination Option
     value needs to be allocated.

     In the combined use of IPsec and the  application  specific  mechanism
     the situation is the same, and only the Destination Option value needs
     to be allocated.

8.6. Standardization Work

     No standardization work outside the Mobile IP WG  is  needed  for  the
     application  specific solution. However, if an existing strong authen¡
     tication protocol needs to be used also, then it needs to be extended.
     This  likely needs IPsec WG involvement. Of course, strong authentica¡
     tion could also be built in to the Mobile IP specific protocols.

     In the use of existing IPsec,  no  standardization  work  outside  the
     Mobile  IP WG is needed.  Even if strong authentication protocols need
     to be used, they can be used as is.

     The extension of IPsec to cover individual Destination  Options  would
     need  an  action from the IPsec WG for a small extension to both IPsec
     and its key management mechanisms.

     The combined use of application specific solution and  IPsec  requires
     no standardization actions, even if strong authentication is needed.

     All  solutions relying on IPsec AH may suffer from the possible action
     in the IPsec WG to deprecate AH. This has been discussed from time  to
     time,  mainly  under the argument of reducing the complexity of IPsec.
     If this happens it may be possible use ESP instead of AH [3].

8.7. Evolution of Authentication Protocols

     Here we discuss the  effects  of  evolving  authentication  protocols.
     Such evolution takes place on two fronts. First, as the weak authenti¡
     cation area is a new one, we can expect new and  better  protocols  to
     appear for this purpose. Secondly, also the current strong authentica¡
     tion protocols and IPsec are under evolution, such as the work on Son-
     of-IKE which has been prompted by the complexity of IKE.

     The  application  specific solution can - if designed right - accommo¡
     date new weak authentication protocols easily. It is necessary to pro¡
     vide  a clean separation between the BU protection and the authentica¡
     tion protocol, but this should be easy.

     The application specific solution can also accommodate existing strong
     authentication, provided that they are extended to support the BU pro¡
     tection protocols. The ability of this solution to follow  the  evolu¡
     tion  of  such  strong authentication protocols depends heavily on the
     interest of their developers to retain non-IPsec support in the proto¡
     col  if it is extended, simplified, or redesigned. It is therefore not
     fully certain that new protocols also allow the same thing.





     J. Arkko                   Expires May 2002                  [Page 22]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     The use of existing IPsec is more certain to be possible even  if  the
     keying protocols evolve. If IPsec is extended to cover also individual
     Destination Options, new keying protocols should also be  able  to  do
     this.  Unless  there  is  a  desire  to simplify things, but one could
     expect that such simplification could be  foreseen  as  the  extension
     itself is discussed.

     The  combined  use of application specific protection and IPsec allows
     evolution both in the weak and in the strong authentication protocols.

8.8. Error Situations

     Application  layer mechanisms in general have more context information
     available regarding various error situations than IP layer  solutions.
     IPsec discards packets if they are in any way unexpected. The question
     regarding BU protection is if there are  any  situations  where  other
     treatment of BU protection error cases is needed than discarding.

     For  instance, if the last message of an authentication protocol would
     happen to arrive after the first protected BU  has  been  sent,  IPsec
     would  simply  discard the packet while an application specific mecha¡
     nism might store it in the anticipation of completing the  authentica¡
     tion  soon.  It isn't clear how important this case is, however. There
     might also be some DoS implications on doing this.

     Another problem appears with weak authentication protocols that piggy¡
     back  the authentication / key agreement messages in the final BU that
     is sent from the MN to the CN. Here,  the  BSA  should  exist  as  the
     packet  is  being processed, but the BSA will actually be created only
     after looking a the authentication  option  in  the  packet.  For  the
     application  specific security, it is easier to e.g. process BU subop¡
     tions in a specific order, but for IPsec AH the processing happens  at
     a  predefined  order.  Some weak authentication schemes such as [6] do
     not have a problem with this, because they have specified an  ordering
     that allows the BSA establishment to take place before the BSA is cre¡
     ated. Some others such as [18] make use of BU  suboptions,  making  it
     harder  to  create  an  IPsec SA at the same time the option itself is
     being processed. The practical effects of this issue is that  the  use
     of IPsec forces either a separated authentication packet, or an order¡
     ing of the Destination Option and AH headers.

8.9. Optimizations for Busy Servers

     It is possible that on some busy servers  the  computation  or  memory
     loads  exceed  the capabilities of the hardware. It is possible though
     for server manufacturers to add a feature that enables the  device  to
     age BUs faster and/or refuse weak authentication and optimized routing
     if the load grows too high.

     The optimizations for IPsec are similar to those for application  spe¡
     cific  protection of BUs. The main optimization is reducing the number
     of BSAs, and the use of optimized routing.





     J. Arkko                   Expires May 2002                  [Page 23]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     In the combined  alternative,  similar  optimizations  exist  for  the
     application specific protection as has been described earlier. For the
     additional IPsec protection,  there  aren't  such  possibilities.  The
     security  policies require the use of IPsec for the traffic within the
     part of the network that is expected to be protected.

8.10. Address Ownership

     In all alternatives, it is assumed that  the  authentication  protocol
     somehow  determines  the right of a particular peer to claim ownership
     of a particular address. For instance, BAKE relies on  the  difficulty
     of  an  eavesdropper  to  simultaneously  see messages along different
     paths to prove a weak form of address ownership [6]. An BSA is  estab¡
     lished after the determination is made.

     This is, however, not enough. It is also necessary to ensure that sub¡
     sequent communications do not  violate  the  address  ownership.   For
     instance,  a  MN  might establish a legitimate BSA with a CN, and then
     use this BSA to send a binding update for another MN.

     In the application specific solution, it is necessary to  ensure  that
     the  BSA  is  used only with respect to the same Home Address that was
     used also for the authentication part.  Currently,  this  hasn't  been
     specified in the draft, but could easily be added.

     In the case of IPsec, the dynamic updates to the SPD and/or the selec¡
     tors in the SAD must be used to create the same effect.  The  individ¡
     ual  policy  entries,  or the selectors of each SA would be set to the
     particular addresses used in the communications. Note  that  like  all
     other  IP  and  higher layer processing, IPsec policy matching is per¡
     formed on the used home addresses rather than Care-of-Addresses.  This
     means  that  the  given  SA  can  only  be used with the original Home
     Address.

     In the case of combined use of application specific and  IPsec  mecha¡
     nisms, both solutions presented above are used together.

8.11. Implementation Aspects

     The  application specific solution can be programmed in isolation from
     the rest of the IPv6 stack. No new APIs are needed  for  the  security
     part. Security association lookup can be performed using the same data
     structures that are used for finding Binding  Cache  entries.  (We  do
     need  to allow for multiple BSAs towards the same peer, but given that
     they would typically be just 1 or 2 it doesn't  appear  to  require  a
     very optimized search tree.)

     On  the  busiest  servers, it might be necessary to provide some hard¡
     ware-level acceleration  mechanisms.   Some  existing  hardware  chips
     could  be used for this purpose, though some other chips are more tai¡
     lored towards specific IPsec processing, and are not applicable.

     If IPsec is used, then an API is needed towards  the  SPD  and/or  the
     SAD,  so  that  the  Mobile IPv6 implementation can add/delete entries



     J. Arkko                   Expires May 2002                  [Page 24]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     from them.

     It is also necessary to ensure that the IPsec implementation is  capa¡
     ble  of  handling large amounts of SPD and SAD entries efficiently, if
     the stack is going to be used in servers that have many clients.  This
     may  mean  improving the SPD matching mechanisms and/or SAD lookup. In
     the case of normal IPsec processing, there  doesn't  exist  a  similar
     Binding Cache entry that was used in an optimized lookup in the appli¡
     cation specific solution. (However,  there  may  be  possibilities  to
     optimize  this  even for IPSec when just BU protection but not general
     IPsec functionality is needed, as discussed in section 8.4.)

     IPsec implementations may take advantage of existing  hardware  chips,
     and their use in current and future products.

     IPsec  implementations in general are more complex than providing just
     the -14 mechanisms.

9.   Conclusions

     The purpose of this memo is to mainly list  the  solutions  and  their
     respective  advantages and disadvantages. We do not make a recommenda¡
     tion here to select a particular solution as some of the pros and cons
     are  not  easy  to  weight against each other.  We hope, however, that
     this memo helps the Mobile IP Working Group to see the complete situa¡
     tion,  and  reach  a consensus on how the solutions weigh against each
     other.

     However, the author would like to offer a few observations:

     - It is crucial for the selection that  we  decide  what  the  minimum
     level  of  security  offered will be. If the WG wants to have security
     where keying material is not created at  all,  it  appears  that  only
     application  specific  solutions  are possible (possibly combined with
     IPsec).  Note that the keying material  generation  in  e.g.  BAKE  is
     intended  to  be an optimization, caching the knowledge that a certain
     type of return routability was verified. Without the keying  material,
     a BAKE-like check needs to be performed for all BUs.

     -  Another crucial decision is the 'philosophical approach' we want to
     take. The approaches are discussed in the beginning of chapter 6.

     - In header overhead, the application specific solution is the  small¡
     est  one,  though  the  difference is not big (17 versus 24 bytes). If
     both application specific and IPsec mechanisms are used, the  overhead
     is large but only when strong authentication is also applied.

     -  Preliminary  results regarding the effects of piggybacking indicate
     that typical header compression mechanisms result in similar bandwidth
     usage for both piggybacked and non-piggybacked cases. Essentially, the
     changing components of packets need to be sent. However, these results
     depend  a lot on the particular situation, compression end-point loca¡
     tion, and so on.  Also, the effect for stationary BU receivers is dif¡
     ferent  than  for  BU  senders  that  may  have  to  start  with a new



     J. Arkko                   Expires May 2002                  [Page 25]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     compression context after movements.  It should be  noted  that  there
     are  complexity, QoS channel reservation, and other issues with piggy¡
     backing so it is not clear that it is always desireable.

     - In particular, piggybacking makes cellular network channel  reserva¡
     tions hard and/or inefficient. Such reservations are necessary on some
     networks, and it is not  possible  to  reserve  space  for  occasional
     Mobile IP signaling in them.

     -  Strong  authentication  should  be allowed as an option for certain
     organizations. In those organizations, there  is  likely  a  need  for
     securing  other  traffic as well, and it might be wise to consider not
     duplicating the configuration effort etc.  for  Mobile  IP  and  other
     applications.

     -  Adding  strong authentication support to protocols such as BAKE may
     not be easy. Relatively complex PKI protocols have to be managed, some
     organizations  would  prefer legacy authentication schemes which would
     make even the PKI approach insufficient, etc.

     - IPsec allows easier evolution in the authentication protocols.   For
     instance,  organizations  that require strong authentication could use
     legacy as well as PKI-based authentication  through  IPSRA  solutions.
     The  modification of e.g. IKE to support also the application specific
     protection is not a recommended approach.

     - It is possible to use IPsec for BU protection without  modifications
     to  the IPsec standards.  However, Mobile IPv6 will have to be changed
     to use a separate protocol number for the BUs and not allow piggyback¡
     ing.   In  this  alternative, a new IPv6 protocol number (or UDP port)
     would have to be allocated, which can be considered  a  more  valuable
     resource than the current Destination Option values.

     -  It is also possible to extend IPsec policy mechanisms and then keep
     Mobile IPv6 unchanged. However,  while  the  modifications  are  small
     there are currently a number of other things on the table in the IPsec
     WG, and therefore making these extensions might cause a delay.

     - There doesn't seem to be a huge  performance  difference  among  the
     solutions in the sense of cryptographic computations. Possible perfor¡
     mance differences can be found in  the  policy  matching  area,  where
     IPsec needs to do work that is more straightforward in the application
     specific solution (though it still needs to be done). It  is  hard  to
     quantify  these,  however,  as the implementations differ in how effi¡
     ciently they have solved the issue. This is relevant mainly  for  very
     large servers with large Binding Caches.

     -  Optimizations for busy servers are possible in all presented alter¡
     natives. IPsec demands more memory per BSA, though.

     - Address ownership issues can be solved all of the presented alterna¡
     tives.





     J. Arkko                   Expires May 2002                  [Page 26]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     -  IPsec  is  more complex to implement than the pure application spe¡
     cific solution. On the other hand, one can take advantage of  existing
     hardware  and software support on a number of products. This situation
     may continue in the future as well, as BU protection  may  not  be  in
     sufficiently high demand to force server vendors to have hardware sup¡
     port for it.

     - In complexity, the main focus should be paid to the  key  management
     parts  rather  than  the IPsec or -14 parts, because that's where most
     complexity lies. An added complexity in the BU protection part may  be
     justifiable  if  a larger complexity reduction can be achieved then on
     the key management part.

10.  Further Work

     The author seeks feedback from the Mobile IP and security  communities
     to  verify  that the presented solutions are complete, secure, and can
     be implemented.

     This memo discusses only the BU protection issue and leaves  the  weak
     authentication  mechanisms to be discussed by other work. Likewise, we
     take no stand in the selection or future development of strong authen¡
     tication mechanisms such as IKE, Son-of-IKE, KINK, and others.

     The  security between the Home Agent and the Mobile Node isn't covered
     in this memo, even if it also involves the use of Binding Updates.  It
     is likely that strong security could be applied in this context, given
     that there the home and the mobile have a pre-arranged relationship.

     The current version of this memo discusses only the use of  IPSec  AH.
     It  may be possible to use also ESP as is discussed in [3]. This might
     become necessary if we get an indication that the AH protocol would be
     deprecated (which is periodically discussed by the IPSec WG).

     Hiding  the  home  address of mobile nodes hasn't been considered as a
     requirement for this work. There might be some possibilities for doing
     this  through  the  placement of the BUs after an ESP header. However,
     this would need to be done for all traffic and not just the BUs. Also,
     what  has  been  stated  in  this  document about the policy rules and
     selectors that match the home address would no longer hold.

     Michael Thomas has suggested that existing strong authentication  pro¡
     tocols  such  as IKE could be used as-is even for the weak authentica¡
     tion, by employing self-signed  certificates.  The  main  drawback  of
     using  exclusively  these  protocols for this purpose is that too many
     roundtrips would be required.

     The terminology used in the draft has been the subject of some discus¡
     sion  on  the  mailing  list. In particular, the terms "piggybacking",
     "weak authentication", and "strong authentication" are not very  accu¡
     rate  and  can  at times be misleading. Due to lack of time, I haven't
     yet included better suggestions in to this draft (I'm not  even  quite
     sure if there are better suggestions).




     J. Arkko                   Expires May 2002                  [Page 27]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


11.  Acknowledgements

     The  author would like to thank Charlie Perkins, Michael Thomas, Pekka
     Nikander, Phil Roberts, Thomas Narten, Hesham Soliman,  Glenn  Morrow,
     Lars-Erik  Jonsson,  Erik  Nordmark,  Greg  O'Shea, and members of the
     Mobile IP mailing list for extensive discussions about the  issues  on
     the  mailing  list. Credit for all solutions and their respective pros
     and cons is fully due to the participants in these discussions.

12.  References

     [1] D. Johnson, C. Perkins, "Mobility Support  in  IPv6",  draft-ietf-
     mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001.

     [2]  P.  Nikander,  D. Harkins, B. Patil, P. Roberts, E.  Nordmark, T.
     Narten, A. Mankin,  "Threat  Models  introduced  by  Mobile  IPv6  and
     Requirements   for  Security  in  Mobile  IPv6",  draft-team-mobileip-
     mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001.

     [3] M. Thomas, "ESP Protected Binding Updates", draft-thomas-mobileip-
     esp-bu-00.txt (unpublished).  July, 2001.

     [4]  D.  Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409,
     November 1998.

     [5] D. Piper, "The Internet IP Security Domain of  Interpretation  for
     ISAKMP", RFC 2407, November 1998.

     [6] P. Nikander, C. Perkins, "Binding Authentication Key Establishment
     Protocol  for  Mobile  IPv6",   draft-perkins-bake-01.txt.   Work   In
     Progress, IETF, July 2001.

     [7]  G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses",
     draft-montenegro-sucv-01.txt.  Work In Progress, IETF, July 2001.

     [8] M. Thomas, D. Oran, "Home  Agent  Cookies  for  Binding  Updates",
     draft-thomas-mobileip-ha-cookies-00.txt.  Work In Progress, IETF, July
     2001.

     [9] J. Rajahalme, on the Mobile IP mailing list, August 21st, 2001.

     [10] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikan¡
     der-ipng-address-ownership-00.txt.   Work  In Progress, IETF, February
     2001.

     [11] S. Kent, R. Atkinson, "Security  Architecture  for  the  Internet
     Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.

     [12]  C.  Bormann  et al, "RObust Header Compression (ROHC): Framework
     and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, TZI/Uni
     Bremen,  Matsushita,  Univ.  of  Arizona,  Ericsson, Cisco, Nokia, NTT
     DoCoMo, July 2001.





     J. Arkko                   Expires May 2002                  [Page 28]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     [13] R. Elz, "The IPv6 Payload Header", Work In Progress, IETF, April,
     1996.

     [14]  SSH  Communications  Security,  "SSH IPSEC Express Performance",
     http://www.ssh.com/products/ipsec/performance.cfm.

     [15] Netscreen, "Meeting the Security Needs of  the  Broadband  Inter¡
     net", http://www.netscreen.com/products/ns1000_wpaper.html.

     [16]  SSH Communications Security, "SSH IPSEC Express Specifications",
     http://www.ssh.com/products/ipsec/specs.cfm.

     [17] D. Katz, "IP Router Alert Option". RFC 2113, February 1997.

     [18] M. Roe et al. "Authentication of Mobile IPv6 Binding Updates  and
     Acknowledgments",    draft-roe-mobileip-updateauth-01.txt.   Work   In
     Progress, IETF, November 2001.

     [19] R. Wakikawa, on the Mobile IP mailing list, October 4th, 2001.

     [20] F. Dupont, on the Mobile IP mailing list, October 4th, 2001.

     [21] Lars-Erik Jonsson, private communication, October 8th, 2001.

     [22] E. Nordmark,  "Securing  MIPv6  BUs  using  return  routability",
     draft-nordmark-mobileip-bu3way-00.txt.  Work In Progress, IETF, Novem¡
     ber 2001.

     [23] J. Arkko, "Security Framework for  Mobile  IPv6  Route  Optimiza¡
     tion",  draft-arkko-mipv6ro-secframework-00.txt.   Work  In  Progress,
     IETF, November 2001.

13.  Revision History

     The following modifications have been done since the -00 version:

     - Added text in 6.4 to indicate that it may be possible to disable the
     application specific protection where (and when) IPsec is available as
     suggested by Charlie Perkins.

     - Added new references for the non-SA models.

     - Added a discussion at the end of 8.3 on the need to run AH MACs  for
     every  packet, but being able to avoid that in the BU suboption model,
     as suggested by Vijay Devarapalli.

     - Added a discussion of BU suboption schemes being able make a  faster
     SA/policy lookup.

     -  Section  7.5 discusses the possibility that the weak authentication
     protocols would have to run outside DOs, and the effect  (if  any)  it
     has on BU piggybacking.





     J. Arkko                   Expires May 2002                  [Page 29]


     INTERNET-DRAFT                MIPv6 BUSec             20 November 2001


     - Changed configuration discussions under chapter 6 to remove the pos¡
     sibility of turning off security, as suggested by Erik Nordmark.

     - Added a discussion of various types of piggybacking, as suggested by
     Erik Nordmark.

     - Clarified the increase of CPU need as the packet size grows to apply
     only for small packets.

     - Clarified the BU and payload reordering impacts for MNs with  estab¡
     lished BCEs, as suggested by Erik Nordmark.

     14.  Author's Address

     Jari Arkko
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland

     Phone: +358 40 5079256 (mobile)
            +358  9 2992480 (office)
     EMail: Jari.Arkko@ericsson.com



































     J. Arkko                   Expires May 2002                  [Page 30]


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