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

Versions: 00 01                                                         
     Network Working Group                                       Jari Arkko
     INTERNET-DRAFT                                                Ericsson
     <draft-arkko-mipv6-bu-security-00.txt>                    October 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 March 1, 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 April 2002                  [Page 1]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


       4.          Introduction.........................................2
       5.          Main Requirements....................................3
       6.          Solutions............................................4
         6.1.      Application Specific Protection......................5
         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..9
       7.          Piggybacking Binding Updates.........................11
         7.1.      Implications to Protecting BUs with IPsec............11
         7.2.      Implications to IPsec Protection of Other Traffic....11
         7.3.      Bandwidth Implications...............................12
         7.4.      QoS Implications.....................................13
         7.5.      Other Implications...................................14
         7.6.      Other Solutions to the Piggybacking Problem..........15
       8.          Comparison of Solutions..............................16
         8.1.      Requirements Fulfillment.............................17
         8.2.      Header Overhead......................................18
         8.3.      Computational Overhead...............................18
         8.4.      Memory and State Requirements........................20
         8.5.      IANA Requirements....................................21
         8.6.      Standardization Work.................................21
         8.7.      Evolution of Authentication Protocols................21
         8.8.      Error Situations.....................................22
         8.9.      Optimizations for Busy Servers.......................22
         8.10.     Address Ownership....................................23
         8.11.     Implementation Aspects...............................23
       9.          Conclusions..........................................24
       10.         Further Work.........................................26
       11.         Acknowledgements.....................................27
       12.         References...........................................27
       13.         Author's Address.....................................28

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 April 2002                  [Page 2]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 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.

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 April 2002                  [Page 3]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 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 April 2002                  [Page 4]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 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 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 Michael Roe's proposal [18]. If these simpler  methods
     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.

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



     J. Arkko                  Expires April 2002                  [Page 5]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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,  beyond possibly turning security on. All BUs and their acknowl-
     edgements will be required protection, by the software taking care  of
     the  mobile IP functionality. In this mechanism, it would also be pos-
     sible to allow both secured and unsecured 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.

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



     J. Arkko                  Expires April 2002                  [Page 6]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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, 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



     J. Arkko                  Expires April 2002                  [Page 7]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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, the user can turn on or off the protection,
     either globally or on a 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



     J. Arkko                  Expires April 2002                  [Page 8]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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



     J. Arkko                  Expires April 2002                  [Page 9]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.
     First,  it becomes necessary to configure the Mobile IP security which
     is likely to consist of turning on/off  the  security  protection.  As
     described  in  section  5.1,  it may also be possible to to allow both
     secured and unsecured BUs which would also have to be configured.  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:
         - BU security: on for *

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



     J. Arkko                  Expires April 2002                 [Page 10]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

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.

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



     J. Arkko                  Expires April 2002                 [Page 11]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

     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



     J. Arkko                  Expires April 2002                 [Page 12]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     mechanisms  and other techniques are typically used. As an example, we
     have considered the ROHC header compression schemes [12].   Its  adop-
     tion  in  various cellular standards as a compression mechanism justi-
     fies 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
     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



     J. Arkko                  Expires April 2002                 [Page 13]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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




     J. Arkko                  Expires April 2002                 [Page 14]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

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

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.




     J. Arkko                  Expires April 2002                 [Page 15]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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:

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




     J. Arkko                  Expires April 2002                 [Page 16]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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

     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.





     J. Arkko                  Expires April 2002                 [Page 17]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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

     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



     J. Arkko                  Expires April 2002                 [Page 18]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

     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.

     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.




     J. Arkko                  Expires April 2002                 [Page 19]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

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



     J. Arkko                  Expires April 2002                 [Page 20]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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.

     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.





     J. Arkko                  Expires April 2002                 [Page 21]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

     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



     J. Arkko                  Expires April 2002                 [Page 22]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     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.

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




     J. Arkko                  Expires April 2002                 [Page 23]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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




     J. Arkko                  Expires April 2002                 [Page 24]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


     -  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 compres-
     sion context after movements.  It should be noted that there are  com-
     plexity,  QoS  channel reservation, and other issues with piggybacking
     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.




     J. Arkko                  Expires April 2002                 [Page 25]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 2001


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

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





     J. Arkko                  Expires April 2002                 [Page 26]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 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, 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 April 2002                 [Page 27]


     INTERNET-DRAFT                MIPv6 BUSec              10 October 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,  "Authentication  of  Mobile  IPv6  Binding Updates and
     Acknowledgments",   draft-roe-mobileip-updateauth-00.txt.   Work    In
     Progress, IETF, August 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.

13.  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 April 2002                 [Page 28]