One document matched: draft-haddad-mipshop-optisend-01.txt
Differences from draft-haddad-mipshop-optisend-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:18:13 |