Mobility Optimizations W. Haddad
Internet-Draft S. Krishnan
Expires: January 10, 2008 Ericsson Research
J. Choi
Samsung AIT
J. Laganier
Docomo Euro-Labs
July 9, 2007
Secure Neighbor Discovery (SeND) Optimizations: The OptiSeND Protocol
draft-haddad-mipshop-optisend-03
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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Haddad, et al. Expires January 10, 2008 [Page 1]
Internet-Draft OptiSeND July 2007
Abstract
This memo describes a new set of mechanisms, which aim to increase
the Secure Neighbor Discovery protocol usability, provide additional
deployment incentives and a better adaptation to mobile environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 6
5. Overview of OptiSeND . . . . . . . . . . . . . . . . . . . . . 7
6. New Options and Messages Formats . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Haddad, et al. Expires January 10, 2008 [Page 2]
Internet-Draft OptiSeND July 2007
1. Introduction
Securing Neighbor Discovery Protocol [SeND] has been designed to
mitigate potential threats against IPv6 Neighbor Discovery Protocol
[NDP]. SeND protocol is based uniquely on the Cryptographically
Generated Address [CGA] technology.
The reliance on RSA signature may severely hamper SeND protocol
usability and deployment in the wireless world. This is mainly due
to the fact that the vast majority of mobile devices share a severe
limitation in terms of processing power (and battery consumption).
This memo describes a new protocol called OptiSeND, which aims to
increase SeND protocol usability, provide additional deployment
incentives and a better adaptation to mobile environment.
We achieve our goals by reducing the reliance on RSA signature to
validate the flow of periodic multicast router adverstisement
(RtAdv), authenticating the NDP messages and removing the latency
caused by running the duplicate address detection (DAD) procedure.
Other features may also be provided.
Haddad, et al. Expires January 10, 2008 [Page 3]
Internet-Draft OptiSeND July 2007
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].
Haddad, et al. Expires January 10, 2008 [Page 4]
Internet-Draft OptiSeND July 2007
3. Glossary
Access Router (AR)
The Access Router is the mobile node's default router.
Attached Node (AN)
An attached node (AN) is a node, which is already attached to the
infrastructure via one or many Access Router(s). An AN is able to
validate a multicast RtAdv message(s) without checking its
signature. An AN can be static or mobile.
Soliciting Node (SN)
A soliciting node is a node, which has started the procedure to
attach itself to the infrastructure by sending a router
solicitation (RtSol) message signed with CGA technology to a
selected AR. After exchanging the first RtSol/RtAdv messages, the
SN is supposed to become an AN.
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].
Haddad, et al. Expires January 10, 2008 [Page 5]
Internet-Draft OptiSeND July 2007
4. Motivation and Goal
IPv6 NDP has been designed to enable nodes on the same link to
discover each other's presence and link-layer addresses, to find
routers, and to maintain reachability information about the paths to
active neighbors. NDP is used by both hosts and routers. Its
functions include Neighbor Discovery, Router Discovery, Address
Autoconfiguration and Resolution, Neighbor Unreachability Detection,
Duplicate Address Detection (DAD), and Redirection.
[NDT] describes different threats, which may appear when NDP is
applied without any protection (e.g., public WLAN network). These
threats can materialize on a particular link in a severe disruption
of information exchange, e.g., due to launching DoS attacks against
one or many nodes. SeND protocol has been designed to counter
threats described in the NDT. For this purpose, SeND relies solely
on CGA technology to provide IPv6 address proof of ownership, sign
NDP messages and consequently, build a form of trust relationship
between different nodes. SeND protocol is highly recommended when
attached nodes (ANs) are using NDP to communicate with the
infrastructure and/or between themselves as neighbors.
When SeND protocol is used between nodes and the infrastructure, an
AR is expected to use CGA technology in all messages sent to any AN.
As previously mentioned, CGA technology allows the AR to provide a
proof of ownership of its claimed IP address(es) and enables the
receiving node(s) to validate information carried in these messages.
Note that the SN may or may not be SeND enabled and thus may not be
able to secure the RtSol message sent to the AR(s). Similarly,
applying SeND protocol to secure NDP exchange enables each node to
provide a proof of ownership of its newly configured IP address(es),
thus eliminating certain malicious behavior, e.g., when checking its
uniqueness via the DAD procedure.
The main goal of this document is to provide an alternative solution
to the RSA signature, which one one side, encourages all nodes to use
SeND and increases the deployment scale, but on the other side,
eliminates the reliance on CGA technology whenever possible. Our
current design is limited to the exchange of NDP messages between AN
and the infrastructure and slightly cover the ND messages exchange
between neighbors. This part is left for future work.
Haddad, et al. Expires January 10, 2008 [Page 6]
Internet-Draft OptiSeND July 2007
5. Overview of OptiSeND
The first goal behind designing OptiSeND protocol is to eliminate the
need for ANs to validate RSA signatures whenever possible. We
achieve our goal by exploiting the fact that the content of the
router advertisement message itself does not get modified frequently.
It follows that prefixes advertised on one particular link together
with their associated parameters are likely to appear unmodified in
each subsequent RA message. However, there are cases where prefixes
do change when renumbering is needed. Such scenario is also
supported in our approach.
In the following, we refer to such message (i.e., plain message) by
RA message and we use the RtAdv notation to refer to an RA message
with SeND protection, i.e., carrying RSA signature and associated
parameters.
Another goal is to enable each SN to share a secret with its AR when
exchanging the first pair of RtSol/RtAdv messages. The shared secret
is then used to authenticate all NDP messages as they get exchanged
via the AR instead of doing it on the link. The NDP messages re-
routing is needed in order to avoid sharing secrets between each and
every neighbor. In addition, ANs should skip the DAD procedure by
delegating such task to the AR whenever possible, in order to reduce
the handoff latency in a mobile environment.
OptiSeND protocol removes the need to verify RSA signatures in an
entire set of RtAdv messages carrying an identical multicast RA
message, except for the first one, which MUST be sent to the SN in
unicast mode. Note that in our context, "identical" refers to
prefixes and associated parameters. We achieve this goal in two
steps. The first one consists on using a particular OWHC value as a
"hook" to enable the SN to quickly validate the sequence of
subsequent RtAdv messages. Such requirement imposes on the AR to
send to the SN the last disclosed value, i.e., to be used as the
hook, of its OWHC. For this purpose, the OWHC value is carried by
the unicast (and first) RtAdv message. The second step is achieved
by inserting in the same (first) unicast RtAdv message sent to the SN
the hash value, i.e., called "Z", of the next RtAdv message
concatenated with the next, i.e., yet undisclosed, OWHC value and the
next timestamp value. This means that if OWHC[i] is the last
disclosed OWHC value sent to the SN, then "Z" is computed in the
following way:
Z = First [ 64, Hash [ RA[i+1] | OWHC[i+1] | Timestamp[i+1] ] ]
Where:
Haddad, et al. Expires January 10, 2008 [Page 7]
Internet-Draft OptiSeND July 2007
- "Z" is the hash value inserted in a new option in the RtAdv
message.
- First (size, input) indicates truncation of "input" data so that
only the first "size" bits remain to be used.
- RA[i+1] is the next multicast router advertisement sent after
sending the unicast RtAdv to the SN.
- OWHC[i+1] is the new and undisclosed value of the OWHC.
- Timestamp[i+1] is the timestamp value which is sent in the next
RtAdv message, i.e., RtAdv[i+1].
It follows that the content of the unicast RtAdv message sent to the
SN is as it follows:
RtAdv[i] = { RA[i] | Z | OWHC[i] | Timestamp[i] | SIG(Kp, RtAdv[i] }
Where SIG(K, M) is the signature computed over the entire message M
with key K.
Such procedure is then repeated in each subsequent multicast RtAdv
messages sent on the link. Doing so, enables ANs to easily validate
all subsequent multicast RtAdv messages by checking first if the
disclosed OWHC value carried in the newly received message is valid
and then use it to compute "Z" and compare it to the one sent in the
previous RtAdv message. Note that the timestamp used in the RtAdv
message will also be used to keep AN(s) synchronized to the OWHC. In
case, an AN misses one multicast RtAdv message, it should solicit a
re-synchronization by sending an authenticated RtSol message. In
this case, the AR SHOULD send back an authenticated unicast RtAdv
message similar to the first one sent to any SN in unicast mode. The
AR MAY also sign the unicast RtAdv message but the signature
validation is not needed.
In a mobile environment, the mobile node (MN) may miss the RtAdv
message due to switching between ARs. In this particular case, the
new AR (nAR) and the MN should share a new secret to authenticate
subsequent NDP messages. It follows that the MN should send a new
RtSol message signed with CGA in order to get an encrypted copy of
the shared secret from the nAR. An optimization to the handoff
procedure would consist on enabling a closer collaboration between
ARs, in order to avoid sharing a new secret each time the MN switches
to a new AR. Such optimization requires secure links and trust
between ARs.
As mentioned earlier, the proposed solution removes the need to
verify the RSA signature in each RtAdv message. This also means that
the AR will always sign each RtAdv message sent in unicast or
multicast mode. However, the AN will first rely on the OWHC
technique to validate its content. In case, crucial data have been
Haddad, et al. Expires January 10, 2008 [Page 8]
Internet-Draft OptiSeND July 2007
modified in the latest multicast RtAdv message, then the signature
MUST be checked. Otherwise, the AN can skip such procedure and store
the carried hash value (Z) whose components will be disclosed in the
next RtAdv. Finally, the AN SHOULD discard any multicast RtAdv
message, which carries a non-valid timestamp unless it has been
received after a layer 2 handoff.
An AR should store in its cache the AN's CGA public key, its MAC
address, the CGA-based interface identifier(s) (IID(s)) and the
corresponding shared secret (called Ks). Storing the IID(s) can also
be used to remove the need for running DAD procedures, and additional
IID(s) MAY be generated from combining Ks with additional parameters.
Note that an AR can store the AN's corresponding parameters for a
limited amount of time after which, it should check again its
presence on the link. Ks is computed by the AR and MUST be sent
encrypted to SN. For this purpose, the AR MUST use SN's CGA public
key sent in the (first) RtSol message to encrypt Ks. The shared
secret should be refreshed when its lifetime expires.
When a NDP messages exchange is needed between two neighboring ANs,
NDP messages MUST be exchanged via the AR in order to avoid using CGA
signature in each message while protecting their integrity. For this
purpose, and in order to avoid inflating each NDP message with an
additional IPv6 header, a new option is defined to indicate to the AR
the destination address to be querried. If the received message is
valid, the AR sends the NDP message to the destination and
authenticates the message with the corresponding shared secret.
After receiving a valid response from the destination, the AR sends
back an authenticated ND message to the sender, which carries the
response provided by the destination.
Haddad, et al. Expires January 10, 2008 [Page 9]
Internet-Draft OptiSeND July 2007
6. New Options and Messages Formats
TBD
Haddad, et al. Expires January 10, 2008 [Page 10]
Internet-Draft OptiSeND July 2007
7. Security Considerations
This memo introduces a new mechanism which is built on top of SeND
protocol. The main goal behind OptiSeND design is to improve the
usability, make a strong(er) case for potential deployment and widen
its scope to include new features. We believe that this goal can be
achieved without introducing new threats nor amplifying existing
ones.
However, expanding OptiSeND protocol in order to enable additional
features, e.g., fast mobility, signaling delegation, etc, requires
secure links and trust between ARs and possibly between ARs and the
access points.
Haddad, et al. Expires January 10, 2008 [Page 11]
Internet-Draft OptiSeND July 2007
8. Acknowledgments
Authors would like to thank Pekka Nikander for his valuable input at
the early stage of this work.
Haddad, et al. Expires January 10, 2008 [Page 12]
Internet-Draft OptiSeND July 2007
9. References
9.1. Normative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3792, March 2005.
[NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)", Internet
Draft, draft-ietf-ipv6-2461bis-11.txt, March 2007.
[NDT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Model and Threats", RFC 3756, May 2004.
[SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971,
March 2005.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
9.2. Informative Reference
[OWHC] Hu, Y., Jakobsson, M., and A. Perrig, "Efficient
Constructions for One-Way Hash Chains", ACNS Conference,
June 2005.
Haddad, et al. Expires January 10, 2008 [Page 13]
Internet-Draft OptiSeND July 2007
Authors' Addresses
Wassim Haddad
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 4044079
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
Julien Laganier
Docomo Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich 80687
Germany
Phone: +49 89 56824 231
Email: Julien.ietf@laposte.net
URI: http://www.docomolab-euro.com
Haddad, et al. Expires January 10, 2008 [Page 14]
Internet-Draft OptiSeND July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haddad, et al. Expires January 10, 2008 [Page 15]