Network Working Group W. Haddad
Internet-Draft S. Krishnan
Expires: August 26, 2006 Ericsson Research
February 22, 2006
Secure Neighbor Discovery (SEND) Optimization and Adaptation for
Mobility: The OptiSEND Protocol
draft-haddad-mipshop-optisend-00
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 August 26, 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 & Krishnan Expires August 26, 2006 [Page 1]
Internet-Draft OptiSEND February 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 . . . . . . . . . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Haddad & Krishnan Expires August 26, 2006 [Page 2]
Internet-Draft OptiSEND February 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 & Krishnan Expires August 26, 2006 [Page 3]
Internet-Draft OptiSEND February 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[.
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
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
Haddad & Krishnan Expires August 26, 2006 [Page 4]
Internet-Draft OptiSEND February 2006
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 & Krishnan Expires August 26, 2006 [Page 5]
Internet-Draft OptiSEND February 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. For the setup of the one-way
hash chain, the generator chooses randomly the root or seed of the
chain, i.e., the value Vn, and derives all previous values Vi by
iteratively applying the hash function H. The value Vo, 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 Vo or the last
"disclosed value" Vd). To verify an input value Vi of a chain, the
verifier iteratively applies the one-way function H i times and
compares the result to the trusted value Vo, i.e., verify that H(Vi)
if applied i times is equal to Vo. If the computed and known values
are equal, then the input value is said to be authentic. Note that
if another value Vj, 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
nor reducing the level of security introduced by the SEND protocol.
Another important future goal is to reduce as much as possible the
use of any authentication mechanism(s) between an ON and its
Haddad & Krishnan Expires August 26, 2006 [Page 6]
Internet-Draft OptiSEND February 2006
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 routing shared secret (Kr) and 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 Vi+1.
Consequently, the sAR MUST send in the unicast RtAdv message
Hash(Vi+1) = Vi (where Vi 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 one-way hash chain thus enabling it to follow and
validate new values sent 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 shared secrets (Ks and Kr) and sends them
to the node in a unicast RtAdv message.
The two shared secrets 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 Kr and
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.
After receiving the unicast RtAdv message, the ON decrypts the two
shared secrets and uses Kr together with the one way hash chain to
check the authenticity of subsequent multicast RtAdv messages. In
Haddad & Krishnan Expires August 26, 2006 [Page 7]
Internet-Draft OptiSEND February 2006
fact, each multicast RtAdv message MUST be authenticated with Kr and
MUST contain one new value from its 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. The ONs
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.
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.
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., generate new 64-bit interface
identifiers (IIDs). Another goal is the fast mobility (described
below). Other goals will be described in a future work. Note that
the lifetime for Ks and Kr is set to 24 hours, after which the ON
SHOULD repeat the procedure described above in order to refresh its
keys.
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
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 fast mobility, OptiSEND protocol delegates additional
responsibilities to the infrastructure in order to address security
requirements related to fast mobility [FMIPv6]. For this purpose,
OptiSEND enables the infrastructure to provide security assistance to
Haddad & Krishnan Expires August 26, 2006 [Page 8]
Internet-Draft OptiSEND February 2006
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.OptiSEND does not
introduce nor amplify new/existing threats compared to SEND.
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,
Haddad & Krishnan Expires August 26, 2006 [Page 9]
Internet-Draft OptiSEND February 2006
"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
Requirement Levels", RFC 2119, BCP , March 1997.
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
Haddad & Krishnan Expires August 26, 2006 [Page 10]
Internet-Draft OptiSEND February 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 & Krishnan Expires August 26, 2006 [Page 11]