[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                          W. Haddad
Internet-Draft                                               S. Krishnan
Expires: September 7, 2006                             Ericsson Research
                                                                 J. Choi
                                                             Samsung AIT
                                                           March 6, 2006


    Secure Neighbor Discovery (SEND) Optimization and Adaptation for
                    Mobility: The OptiSEND Protocol
                    draft-haddad-mipshop-optisend-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo describes a new set of mechanisms, which aims to increase
   the Secure Neighbor Discovery (SEND) protocol usability by reducing
   the required processing power on small devices and adapting it to
   mobile environment requirements while maintaining its efficiency.




Haddad, et al.          Expires September 7, 2006               [Page 1]


Internet-Draft                  OptiSEND                      March 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Problem and Motivation . . . . . . . . . . . . . . . . . . . .  4
   5.  Protocol Requirements  . . . . . . . . . . . . . . . . . . . .  6
   6.  Overview of One-Way Hash Chain . . . . . . . . . . . . . . . .  6
   7.  Overview of OptiSEND . . . . . . . . . . . . . . . . . . . . .  6
   8.  New Options and Messages Formats . . . . . . . . . . . . . . .  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13




































Haddad, et al.          Expires September 7, 2006               [Page 2]


Internet-Draft                  OptiSEND                      March 2006


1.  Introduction

   Securing Neighbor Protocol (SEND) has been designed to mitigate
   potential threats against the IPv6 Neighbor Discovery Protocol (NDP).
   [SEND] protocol is based uniquely on the Cryptographically Generated
   Address (CGA).

   Consequently, SEND relies heavily on using RSA signature, which in
   turn may severely limit its usability and deployment in the wireless
   world, due to the fact that the majority of small mobile devices are
   very limited in terms of processing power and battery consumption.

   This memo describes a new protocol (OptiSEND), which aims to optimize
   SEND by reducing the required processing power on small devices and
   adapting it to mobile environment while maintaining its efficiency.
   OptiSEND is built on top of the SEND protocol.


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [TERM].


3.  Glossary

   Access Router (AR)

      The Access Router is the mobile node's default router.

   Oustide Node (ON)

      An outside node (ON) is a node, which is already attached to the
      infrastructure via one or many Access Router(s).  An ON can be
      static or mobile.

   Selected Access Router (sAR)

      A selected AR is the AR chosen by the MN as the destination node
      for its RtSol message signed with CGA technology.

   Soliciting Node (SN)

      A soliciting node is a node, which has started the procedure to
      attach itself to the infrastructure by sending a RtSol message
      signed with CGA technology to a selected AR (sAR).




Haddad, et al.          Expires September 7, 2006               [Page 3]


Internet-Draft                  OptiSEND                      March 2006



   One-Way Chain

      A one way chain (Vo...Vn) is a collection of values such that each
      value Vi (except the last value Vn) is a one-way function of the
      next value Vi+1.  In particular, we have Vi = H(Vi+1), for i
      belonging to [0,n[.  For clarity purpose and to avoid confusion,
      we'll use in the rest of this document the notation V[i] instead
      of Vi, which means V[i+1] points to Vi+1...

   Neighbors

      Nodes attached to the same link.

   For more details about the one-way chain, please refer to [OWHC].


4.  Problem and Motivation

   SEND protocol has been designed to secure the exchange of the IP
   address(es) and routing information between different nodes as
   described in the Neighbor Discovery [ND] and the IPv6 Stateless
   Address Autoconfiguration [STAT] Protocols.  Such exchange is
   required in two different scenarios.  The first one is when a mobile/
   static node requests routing, network parameters and IP layer address
   configuration(s) information from the infrastructure.  This is done
   via sending and/or receiving information from one or many access
   router(s) (AR).  The second scenario occurs when different nodes
   located on the same link exchange their IP and MAC addresses between
   themselves.

   [ND_T] describes different threats, which may appear if/when NDP is
   applied without any protection (e.g., in a public network).  These
   threats cover both scenarios and may severely disrupt the exchange of
   information on one particular link, e.g., by launching DoS attacks
   against one or many nodes.  In order to address these issues, SEND
   relies solely on the Cryptographically Generated Addresses technology
   (described in [CGA]) to provide a proof of ownership, and
   consequently to build a form of trust relationship betweeen different
   nodes.  For this purpose, SEND is highly recommended when outside
   nodes (ONs) are using NDP to talk to the infrastructure and between
   themselves (i.e., if they are neighbors).

   When the SEND protocol is used between the nodes and the
   infrastructure, an AR is expected to use the CGA technology in all
   messages sent to any node trying to attach itself to the
   infrastructure.  As already mentioned, CGA technology allows the AR
   to provide a proof of ownership of its claimed IP address(es) and



Haddad, et al.          Expires September 7, 2006               [Page 4]


Internet-Draft                  OptiSEND                      March 2006


   enables the receiving node(s), i.e., ON(s), to validate all
   information carried in these messages.  Note that in this particular
   scenario, the ON is not required to use SEND when sending a router
   solicitation (RtSol) message to the AR(s).
   Similarly, applying SEND protocol between a set of nodes attached to
   the same AR(s), enables each node and by always relying on the CGA
   technology, to provide a proof of ownership of its newly configured
   IP address(es) and to defend its uniqueness on one particular link,
   during a duplicate address detection (DAD) procedure.

   However, SEND reliance on the RSA signature (as inherent part of the
   CGA technology) is raising questions concerning the cost and scale of
   its usability and deployment.  These questions become more pertinent
   when the mobility aspect is added to the original problem related to
   limited processing and battery power devices.  In fact, each time the
   MN switches to a new access point (AP), i.e., perform a link layer
   handoff, it has to check if it is still attached to the
   infrastructure via the same AR(s) or if it needs to attach to another
   part or simply a new one.  Consequently, a fast moving node will have
   to dedicate a considerable amount of its power processing cycles to
   process RSA signatures in order to validate RtAdv messages sent by
   previous and new AR(s).  Similarly, after configuring a new IP
   address, the mobile node (MN) has to use SEND to exchange NDP
   messages with other nodes.  Note that the presence of at least one
   malicious node on the same link can strongly and easily contribute in
   exhausting the processing power of the targeted MN and may add
   significant delay during handoff procedures.

   In order to enable seamless mobility while running time sensitive
   applications, a new protocol Fast Mobile IPv6 ([FMIPv6]), has been
   standardized and is currently under review.  FMIPv6 relies on
   involving the infrastructure in the handoff process by requiring from
   the previous AR (pAR) and new AR (nAR) to exchange signaling
   information upon receiving a trigger message from the MN (i.e., when
   starting the handoff procedure).  Consequently, using RSA signature
   during this critical phase may add significant delay to the handoff
   procedure (note that the situation gets quickly worse in the presence
   of malicious node(s)).

   The main goal of this document is to provide an alternative solution
   to the RSA signature, which optimizes the use of SEND by reducing the
   power processing cost, increasing the scale of deployability and
   addressing mobility requirements from an early design stage by
   providing a simple way to forward shared secrets between pAR and
   nAR(s).  However, our current design is limited to the exchange of ND
   messages between ON and the infrastructure and does not cover yet the
   exchange of ND messages between neighbors only.  Our future work will
   address these particular scenarios.



Haddad, et al.          Expires September 7, 2006               [Page 5]


Internet-Draft                  OptiSEND                      March 2006


5.  Protocol Requirements

   OptiSEND does not require major change in the ND protocol.  But it
   requires that all AR(s) rely on the one-way hash chains and shared
   secrets to authenticate the RtAdv messages.  Moreover, OptiSEND
   requires that ONs authenticate a special set of messages by using a
   shared secret obtained from using CGA technology when exchanging one
   particular message with AR.  Finally, OptiSEND requires also that ON
   auto-configures additional IPv6 addresses (if/when needed) by using
   the shared secret and other parameters to compute the new interface
   identifier(s) (IID(s)).

   OptiSEND protocol introduces new messages in addition to the existing
   set of messages defined in the ND protocol.  The new messages are
   required to distribute identification and security parameters between
   different ARs.


6.  Overview of One-Way Hash Chain

   When the one way function H() is a cryptographic hash function, then
   the chain is called one-way hash chain (OWHC).  For the setup of the
   one-way hash chain, the generator chooses randomly the root or seed
   of the chain, i.e., the value V[n] (i.e., Vn), and derives all
   previous values V[i] by iteratively applying the hash function H().
   The value V[0], which is considered the end-value, is normally made
   public, and potentially linked to the identity of the user processing
   the corresponding root value.

   In order to verify a one way hash chain values, we assume that the
   ONs attached to the infrastructure know an authentic value of the
   generator's one-way chain (which can be the end-value V[0] or the
   last "disclosed value" V[d]).  To verify an input value V[i] of a
   hash chain, the verifier iteratively applies the one-way function H()
   i times and compares the result to the trusted value V[0], i.e.,
   verify that H(V[i]) if applied i times is equal to V[0].  If the
   computed and known values are equal, then the input value is said to
   be authentic.  Note that if another value V[j], for j < i, is already
   known, then it suffices to iteratively apply the one-way function
   some i-k times to the input value, and compare the result to this
   intermediate value.


7.  Overview of OptiSEND

   The main goal behind designing OptiSEND protocol is to eliminate the
   use of RSA signature whenever possible and/or significantly reduce
   its use, without amplifying existing threats nor introducing new ones



Haddad, et al.          Expires September 7, 2006               [Page 6]


Internet-Draft                  OptiSEND                      March 2006


   nor reducing the level of security introduced by the SEND protocol.
   Another important futur goal is to reduce as much as possible the use
   of any authentication mechanism(s) between an ON and its neighbors.
   In addition, OptiSEND protocol incorporates a solution, which enables
   the MN to perform secure and fast mobility.
   In order to achieve its purposes, OptiSEND protocol addresses
   separately the issue of an outside node talking to the infrastructure
   and the one where an ON is talking with its neighbors.  The current
   proposal deals only with the first scenario.

   For the first case, OptiSEND uses the one way hash chain to allow the
   AR(s) to authenticate their RtAdv messages.  By relying on such
   technique, OptiSEND enables all ONs attached to the infrastructure to
   continue validating the RtAdv messages without having to use
   extensive processing power on validating RSA signature(s).
   In order to achieve such goal, OptiSEND requires that the ON uses CGA
   technology to send its first RtSol message only.  When a particular
   AR gets a RtSol message signed with CGA, i.e., thus becoming a
   selected AR (sAR), it generates a neighbor shared secret (Ks) and
   sends it to the SN along with the hash of the next value (i.e., yet
   undisclosed) in its one way chain in a unicast RtAdv message.
   For clarity purpose, we call the next value to be disclosed in the
   next multicast RtAdv message V[i+1].  Consequently, the sAR MUST send
   in the unicast RtAdv message Hash(V[i+1]) = V[i] (where V[i] is the
   last disclosed value).
   The goal behind inserting the hash of the next one way hash chain
   value in the unicast RtAdv message sent to an SN is to enable it to
   hook itself to the different one-way hash chains used by ARs thus
   enabling it to follow and authenticate new values sent by different
   ARs in subsequent multicast RtAdv messages.
   Note that after sending a RtSol message signed with CGA, the SN may
   receive more than one RtAdv message from multiple ARs attached to the
   same link.  However, the SN may also receive RtAdv messages before
   sending its RtSol message.  In the first scenario, and in order to
   avoid having each AR generating one shared secret and sending it to
   the node in a unicast RtAdv message, ARs SHOULD be able to select one
   AR to generate Ks and then distribute it to them along with the SN
   data.  In the latter case, a node SHOULD select one particular AR and
   sends it a RtSol message signed with CGA.  In such case, the selected
   AR (sAR) will generate the neighbor shared secret (Ks) and sends it
   to SN in a unicast RtAdv message.

   The neighbor shared secret MUST be encrypted with the MN's CGA public
   key and the unicast RtAdv message MUST be signed with CGA.  In
   addition, the sAR MUST insert in the unicast RtAdv message the set of
   the last disclosed OWHC values used by other ARs attached to the same
   link.  For these purposes, the sAR MUST insert new options in the
   RtAdv message.



Haddad, et al.          Expires September 7, 2006               [Page 7]


Internet-Draft                  OptiSEND                      March 2006


   After receiving the unicast RtAdv message, the ON decrypts Ks and
   uses the one-way hash chain to check the authenticity of subsequent
   multicast RtAdv messages via authenticating the OWHC value carried in
   the RtAdv message.  In fact, each multicast RtAdv message MUST carry
   one new value from the AR's one-way hash chain.  Consequently, upon
   receiving a multicast RtAdv message, the ON should check first the
   authenticity of the value carried in the multicast RtAdv message
   before processing or dropping the message.  For this purpose the ON
   should hash the value carried in the RtAdv message and compares it to
   the one disclosed in the last RtAdv message received by the ON.  Note
   that in case the ON misses one RtAdv message and before it re-sends a
   new RtSol message signed with CGA to request a fresh value, it SHOULD
   hash the value disclosed in the latest RtAdv message a maximum X
   times and compares each value to the one stored in its cache entry.
   If after X attempts, the obtained value does not match the stored
   one, then the ON SHOULD re-send a RtSol message signed with CGA in
   order to request a new value and re-synchronize itself.  The ON
   SHOULD silently discard any RtAdv message carrying a value, which has
   already been disclosed in a previous RtAdv message or which is simply
   not authentic.
   The ON SHOULD also authenticate any unicast message sent to an AR
   with its Ks and the AR SHOULD authenticate any unicast message sent
   to one particular ON with its corresponding Ks.  The ON will also use
   Ks for other purposes, e.g., obtaining new end value(s) for new one-
   way hash chain(s), generate new 64-bit interface identifiers (IIDs).
   Another goal is the fast mobility (described below).  Other goals
   will be described in a futur work.  Note that the lifetime for Ks is
   set to 24 hours, after which the ON SHOULD repeat the procedure
   described above in order to refresh its Ks.

   Note that when all values of a particular OWHC have been disclosed,
   the corresponding AR can signal to its visitors (i.e., ONs) the
   availability of a new OWHC by sending a multicast RtAdv message
   signed with CGA and without any value.  Upon receiving such message,
   each ON SHOULD send a unicast RtSol message to the AR to request one
   value (e.g., the end value) in order to hook itself to the new OWHC.
   Note that the ON MUST authenticate the unicast RtSol message with its
   Ks.
   When an AR receives a RtSol message signed with one Ks, it MUST send
   back a unicast RtAdv message, which carries the last disclosed value
   (Vi) of its OWHC.  The sAR MUST encrypt Vi and authenticate the RtAdv
   message.

   In parallel to sending a unicast RtAdv message to the SN, the sAR
   MUST update all other ARs attached to the same link with the new ON
   parameters, which MUST include its MAC address, the shared secret
   (Ks), the IPv6 64-bit interface identifier (IID) and its lifetime.
   For this purpose, the sAR SHOULD send a multicast Binding



Haddad, et al.          Expires September 7, 2006               [Page 8]


Internet-Draft                  OptiSEND                      March 2006


   Advertisement (BdAdv) message to the ARs to request creating a
   visitor cache entry (VCE) for the new ON.  Upon receiving a BdAdv
   message, each AR checks its VCE for an existing entry, which contains
   the corresponding ON's MAC address(es).  If a VCE exists, then the AR
   updates it with the new Ks and its lifetime.  Otherwise, the AR
   SHOULD create a new one.  Note that the BdAdv message MUST be
   encrypted with the AR's CGA private key.

   For the fast mobility, e.g., [FMIPv6] protocol, OptiSEND protocol
   delegates additional responsibilities to the infrastructure in order
   to address security requirements related to FMIPv6.  For this
   purpose, OptiSEND enables the infrastructure to provide security
   assistance to the MN when switching to a new AR by enabling the
   infrastructure to seamlessly forward security credentials to new
   AR(s), in parallel with the moving node, thus enabling the MN to keep
   authenticating its mobility signaling messages with the same key as
   long as such key remains valid.  In the FMIPv6 scenario, this is
   achieved by allowing the previous AR (pAR) to send the MN's Ks, MAC
   address and other parameters to the new Access Router (nAR), upon
   receiving a hint from the MN, e.g., a Fast Binding Update (FBU)
   message signaling an imminent handoff.  The pAR may also send a
   multicast BdAdv message to nAR(s) without waiting for such hint to be
   send by the MN, e.g., case of network triggered handover.  By
   seamlessly forwarding Ks to new AR(s), the MN will be able to secure
   its critical mobility signaling messages by using the same key.
   Moreover, using symetric cryptography allows the MN to keep using
   FMIPv6 procedure even if the nAR/pAR does not recognize the identity
   of one particular AP, e.g., case of a malicious AP(s).


8.  New Options and Messages Formats

   TBD


9.  Security Considerations

   This memo introduces a new protocol, which is built on top of SEND.
   There are two main goals behind the OptiSEND design.  The first one
   is to alleviate the processing power required to validate RSA
   signature without amplifying existing threats nor adding new ones.
   The second goal is to widen the usability scope to include other
   features, which impact the neighbor discovery and the fast mobility
   protocols by fully exploiting the form of trust built between the
   infrastructure and the ON upon attaching to the sAR.

   To achieve the first goal, OptiSEND protocol is built on the
   fundamental assumption that when an operator cares about providing



Haddad, et al.          Expires September 7, 2006               [Page 9]


Internet-Draft                  OptiSEND                      March 2006


   both secure access and secure fast mobility, then the operator's
   infrastructure itself should be already secure.  This means that it
   is assumed in this memo that all links between AR(s) are secure and
   all links between AR(s) and AP(s) are secure.  Consequently, the
   vulnerability to man-in-the-middle attacks is eliminated or
   significantly reduced since using man-in-the middle rogue AP(s) must
   not be possible.

   The second goal is achieved as a direct result from the first one as
   long as the foreign infrastructure(s) remains secure.  In such case,
   OptiSEND does not introduce nor amplify new/existing threats.


10.  Acknowledgments

   Authors would like to thank Pekka Nikander for his valuable input at
   the early stage of this work.

11.  Normative References

   [CGA]     Aura, T., "Cryptographically Generated Addresses (CGA)",
             RFC 3792, March 2005.

   [FMIPv6]  Koodli, R., "Fast Handovers for Mobile IPv6", Internet
             Draft, draft-koodli-mipshop-rfc4068bis-00.txt,
             October 2005.

   [ND]      Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP Version 6 (IPv6)", Internet
             Draft, draft-ietf-ipv6-2461bis-05.txt, October 2005.

   [ND_T]    Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
             Discovery (ND) Trust Model and Threats", RFC 3756,
             May 2004.

   [OWHC]    Hu, Y., Jakobsson, M., and A. Perrig, "Efficient
             Constructions for One-Way Hash Chains", ACNS Conference,
             June 2005.

   [SEND]    Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
             Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971,
             March 2005.

   [STAT]    Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", Internet
             Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005.

   [TERM]    Bradner, S., "Key Words for Use in RFCs to Indicate



Haddad, et al.          Expires September 7, 2006              [Page 10]


Internet-Draft                  OptiSEND                      March 2006


             Requirement Levels", RFC 2119, BCP , March 1997.


















































Haddad, et al.          Expires September 7, 2006              [Page 11]


Internet-Draft                  OptiSEND                      March 2006


Authors' Addresses

   Wassim Haddad
   Ericsson Research
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 #2334
   Email: Wassim.Haddad@ericsson.com


   Suresh Krishnan
   Ericsson Research
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900
   Email: Suresh.Krishnan@ericsson.com


   JinHyeock Choi
   Samsung AIT
   Communication & N/W Lab
   Suwon 440-600
   P.O. Box 111
   KOREA

   Phone: +82 31 280 9233
   Email: jinchoe@samsung.com




















Haddad, et al.          Expires September 7, 2006              [Page 12]


Internet-Draft                  OptiSEND                      March 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Haddad, et al.          Expires September 7, 2006              [Page 13]