association establishment.
If an access router can ensure that the source IP address in an
arriving packet could only have originated from the node whose
Link-Layer Address is in the router’s neighbor cache, then a bogus
node cannot use a victim’s IP address for malicious redirection of
traffic. Such an operation is recommended at least on neighbor
discovery messages including the RtSolPr message.
2. Secure FBU, malicious or inadvertent redirection: In this case,
the FBU is secured, but the target of binding happens to be an
unsuspecting node due to inadvertent operation or malicious
intent. This vulnerability can lead to an MN with a genuine
security association with its access router redirecting traffic to
an incorrect address.
However, the target of malicious traffic redirection is limited to
an interface on an access router with which the PAR has a security
association. The PAR MUST verify that the NCoA to which PCoA is
being bound actually belongs to NAR’s prefix. To do this, HI and
HAck message exchanges are to be used. When NAR accepts NCoA in
HI (with Code = 0), it proxies NCoA so that any arriving packets
are not sent on the link until the MN attaches and announces
itself through FNA. Therefore, any inadvertent or malicious
redirection to a host is avoided. It is still possible to jam
NAR’s buffer with redirected traffic. However, since NAR’s
handover state corresponding to NCoA has a finite (and short)
lifetime corresponding to a small multiple of anticipated handover
latency, the extent of this vulnerability is arguably small.
3. Sending an FBU from NAR’s link: A malicious node may send an FBU
from NAR’s link providing an unsuspecting node’s address as NCoA.
Since the FBU is encapsulated in the FNA, NAR should detect the
collision with an address in use when processing the FNA, and then
drop the FBU. When NAR is unable to detect address collisions,
there is a vulnerability that redirection can affect an
unsuspecting node.
9. IANA Considerations
This document defines four new experimental ICMPv6 messages that use
the Experimental Mobility Protocol ICMPv6 format [4]. These four new
Subtype value assignments out of the Experimental Mobility Protocol
Subtype Registry [4] have been assigned as follows:
Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 HI Section 6.2.1
5 HAck Section 6.2.2
This document defines four new Neighbor Discovery [6] options that
have received Type assignments from IANA.
Option-Type Description Reference
----------- ----------- ---------
17 IP Address Option Section 6.4.1
18 New Router Prefix
Information Option Section 6.4.2
19 Link-Layer Address
Option Section 6.4.3
20 Neighbor Advertisement
Acknowledgment Option Section 6.4.5
This document defines three new Mobility Header messages that have
received type allocations from the Mobility Header Types registry at
http://www.iana.org/assignments/mobility-parameters:
1. Fast Binding Update, described in Section 6.3.1
2. Fast Binding Acknowledgment, described in Section 6.3.2, and
3. Fast Neighbor Advertisement, described in Section 6.3.3.
This document defines a new Mobility Option which has received type
assignments from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
1. Mobility Header Link-Layer Address option, described in Section
6.4.4.
10. Acknowledgments
The editor would like to thank all those who have provided feedback
on this specification, but can only mention a few here: Martin
Andre, Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Suvidh Mathur,
Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC
Peng, Domagoj Premec, and Jonathan Wood. The editor would like to
acknowledge a contribution from James Kempf to improve this
specification. The editor would also like to thank the [mipshop]
working group chair Gabriel Montenegro and the erstwhile [mobile ip]
working group chairs Basavaraj Patil and Phil Roberts for providing
much support for this work.
11. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", RFC 4065, July 2005.
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
12. Contributors
This document originated in the fast handover design team effort.
The members of this design team in alphabetical order were: Gopal
Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham
Soliman, George Tsirtsis, and Alper Yegin.
The design team member’s contact information:
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone:+1 408 525 1404
EMail: gdommety@cisco.com
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
EMail: Karim.El-Malki@era.ericsson.se
Mohamed Khalil
Nortel Networks
EMail: mkhalil@nortelnetworks.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Hesham Soliman
Flarion Technologies
EMail: H.Soliman@flarion.com
George Tsirtsis
Flarion Technologies
EMail: G.Tsirtsis@flarion.com
Alper E. Yegin
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Author’s Address
Rajeev Koodli, Editor
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
EMail: Rajeev.Koodli@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.