replay attacks. Such an attack might lead to bogus registrations or
redirection of traffic or denial of service.
As per the messaging in this document, the Assigned Home Agent will
process the incoming Registration Request as per Mobile IPv4 [1].
Hence the Assigned Home Agent will have the same security concerns as
those of the home agent in Mobile IPv4 [1]. They are addressed in
Section 5, "Security Considerations", of Mobile IPv4 [1].
The Registration Request and Registration Reply messages are
protected by a valid authenticator as specified in Mobile IPv4 [1].
Configuring security associations is a deployment-specific issue and
is covered by other Mobile IP specifications. There can be many ways
of configuring security associations, but this specification does not
require any specific way.
An example is where the security association between an MN and an
individual HA (Requested or Assigned) is dynamically derived during
the registration process based on a shared secret between MN and AAA
infrastructure, as defined in [7]. The Registration Request is
protected with MN-AAA Authentication Extension, and Registration
Reply is protected with MN-HA Authentication Extension. Because the
security association is shared between MN and AAA, any dynamically
assigned HA in the local domain can proxy authenticate the MN using
AAA as per [7].
The Assigned Home Agent authenticates each Registration Request from
the mobile node as specified in Mobile IPv4 [1] and/or RFC 3012. The
MN also authenticates the Registration Reply from the Assigned HA;
thus, the existing trust model in Mobile IPv4 [1] is maintained.
10. Backward-Compatibility Considerations
In this section, we examine concerns that may arise when using this
specification in a mixed environment where some nodes implement the
specification and others do not. In each of the examples below, we
consider the case where one node is a "legacy" node, which does not
implement the specification in the context of other nodes that do.
Legacy Home Agent:
Legacy home agents may reject the Registration Request with error
code 136 because the Home Agent field is not a unicast address.
However, some legacy HA implementations may coincidentally process
the Registration Request in accordance with this document, when the
HA field in Registration Request is set to ALL-ZERO-ONE-ADDR.
Legacy Foreign Agent:
Legacy foreign agents may forward a Registration Request with home
agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP
address to ALL-ZERO-ONE-ADDR. This will result in the packet being
dropped or incidentally handled by a next-hop HA, adjacent to the FA.
The MN may not be aware of the dropped Registration Request and may
probably retry registration, thereby increasing the delay in
registration.
To reduce the delay in registration, the MN should take the following
steps:
1. The MN should send the Registration Request as specified in this
specification. In other words, the MN should set the Home Agent
field in the Registration Request to ALL-ZERO-ONE-ADDR and also
add the Requested HA Extension.
2. If the MN does not receive a Registration Reply within some time
and/or after sending a few Registration Requests, it can assume
that the Registration Request(s) has been dropped, either by a
legacy FA or an incorrect HA. In addition, if the registration
is denied with error code 70 (poorly formed Request), the MN can
assume that the legacy FA cannot process this message. In either
case, the MN should fall back to a recovery mechanism. The MN
should quickly send a new Registration Request as mentioned in
Section 4.1 step 2. This step will ensure that a legacy FA will
forward the Registration Request to the home agent thereby making
dynamic HA assignment possible.
Legacy Mobile Node:
An MN that sends a Registration Request to an FA that can do dynamic
HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR
will continue to be registered with its statically configured HA,
exactly according to RFC 3344.
11. Acknowledgements
The authors would like to thank Pete McCann for thorough review,
suggestions on security considerations, and definition of ALL-ZERO-
ONE-ADDR. Thanks to Kuntal Chowdhury for extensive review and
comments on this document. Also thanks to Henrik Levkowetz for
detailed reviews and suggestions. Thomas Narten highlighted issues
for legacy FA considerations. Thanks to Ahmad Muhanna for pointing
out scenario of multiple bindings on HAs, documented in the Security
Considerations section.
The authors would like to thank Mike Andrews, Madhavi Chandra, and
Yoshi Tsuda for their review and suggestions.
12. Normative References
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[2] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[3] Senie, D., "Changing the Default for Directed Broadcasts in
Routers", BCP 34, RFC 2644, August 1999.
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC 3012, November 2000.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
March 2005.
Authors’ Addresses
Milind Kulkarni
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.com
Alpesh Patel
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Full 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.
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 provided by the IETF
Administrative Support Activity (IASA).