Mobile IPv4 FA Error: Foreign Agent Error Extension for Mobile IPv4
A separate slot in Mobile IPv4 replies where a foreign agent can report errors without breaking the home agent's authentication.
Perkins, C., "Foreign Agent Error Extension for Mobile IPv4", RFC 4636, DOI 10.17487/RFC4636, October 2006, <https://www.rfc-editor.org/info/rfc4636>.
@misc{rfc4636,
series = {Request for Comments},
number = 4636,
howpublished = {RFC 4636},
publisher = {RFC Editor},
doi = {10.17487/RFC4636},
url = {https://www.rfc-editor.org/info/rfc4636},
author = {C. Perkins},
title = {{Foreign Agent Error Extension for Mobile IPv4}},
pagetotal = 6,
year = 2006,
month = oct,
} RFC text
Contents
Network Working Group C. Perkins
Request for Comments: 4636 Nokia Research Center
Category: Standards Track October 2006
Foreign Agent Error Extension for Mobile IPv4
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a new extension for use by Foreign Agents
operating Mobile IP for IPv4. Currently, a foreign agent cannot
supply status information without destroying the ability for a mobile
node to verify authentication data supplied by the home agent. The
new extension solves this problem by making a better place for the
foreign agent to provide its status information to the mobile node.
1. Introduction
This document specifies a new non-skippable extension for use by
Foreign Agents operating Mobile IP for IPv4 [4]. The new extension
option allows a foreign agent to supply an error code without
disturbing the data supplied by the Home Agent within the
Registration Reply message. In this way, the mobile node can verify
that the Registration Reply message was generated by the Home Agent
even in cases where the foreign agent is required by protocol to
insert new status information into the Registration Reply message.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. Other
terminology is used as already defined in [4].
3. FA Error Extension Format
The format of the FA Error Extension conforms to the Short Extension
format specified for Mobile IPv4 [4]. The FA Error Extension is not
skippable.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
45
Length
2
Sub-Type
0
Status
A status code used by the foreign agent to supply status
information to the mobile node.
4. Operation and Use of the FA Error Extension
The FA Error Extension is only valid for use within Mobile IPv4
Registration Reply messages. The FA Error Extension is not
skippable. A mobile node that cannot correctly interpret the
contents of the FA Error Extension MUST NOT use the care-of address
provided in the Registration Reply message, until another
Registration Request message has been sent and a successful
Registration Reply message received.
Status codes allowable for use within the FA Error Extension are
within the range 64-127. The currently specified codes are as
follows:
64 reason unspecified
65 administratively prohibited
66 insufficient resources
68 home agent failed authentication
71 poorly formed Reply
77 invalid care-of address
78 registration timeout
as defined in RFC 3344 [4] for use by the Foreign Agent. Status
codes for use with the FA Error extensions must not be differently
defined for use in the Code field of Registration Reply messages.
When a foreign agent appends a FA Error Extension to the Registration
Reply as received from the Home Agent, it has to update the UDP
Length field in the UDP header [5] to account for the extra 4 bytes
of length.
This document updates the Mobile IP base specification [4] regarding
the procedures followed by the foreign agent in the case that the
home agent fails authentication. Instead of modifying the "status"
field of the Registration Reply to contain the value 68, now the
foreign agent should append the Foreign Agent Error Extension
containing the status value 68.
5. Mobile Node Considerations
If a mobile node receives a successful Registration Reply (status
code 0 or 1), with a FA Error Extension indicating that the foreign
agent is not honoring said Registration Reply, the mobile node SHOULD
then send a deregistration message to the home agent. In this way,
the home agent will not maintain a registration status that is
inconsistent with the status maintained by the foreign agent.
6. Foreign Agent Considerations
When denying a successful Registration Reply, the Foreign Agent
SHOULD send a Registration Revocation message [2] to the Home Agent
if a mobility security association exists between them. For cases
when the foreign agent does have the required security association,
this way of informing the home agent does not have the vulnerability
from detrimental actions by malicious foreign agents, as noted in
section 8.
7. IANA Considerations
This specification reserves one number for the FA Error Extension
(see section 3) from the space of numbers for non-skippable mobility
extensions (i.e., 0-127) defined in the specification for Mobile IPv4
[4].
This specification also creates a new number space of sub-types for
the type number of this extension. Sub-type zero is to be allocated
from this number space for the protocol extension specified in this
document. Similar to the procedures specified for Mobile IP [4]
number spaces, future allocations from this number space require
expert review [3].
The status codes that are allowable in the FA Error Extension are a
subset of the status codes defined in the specification for Mobile
IPv4 [4]. If, in the future, additional status codes are defined for
Mobile IPv4, the definition for each new status code must indicate
whether the new status code is allowable for use in the FA Error
Extension.
8. Security Considerations
The extension in this document improves the security features of
Mobile IPv4 by allowing the mobile node to be assured of the
authenticity of the information supplied within a Registration
Request. Previously, whenever the foreign agent was required to
provide status information to the mobile node, it could only do so by
destroying the ability of the mobile device to verify the Mobile-Home
Authentication Extension data.
In many common cases, the mobile node will not have a security
association with the foreign agent that has sent the extension.
Thus, the mobile node will be unable to ascertain that the foreign
agent sending the extended Registration Reply message is the same
foreign agent that earlier received the associated Registration
Request from the mobile node. Because of this, a malicious foreign
agent could cause a mobile node to operate as if the registration had
failed, when in fact its home agent and a correctly operating foreign
agent had both accepted the mobile node's Registration Request. In
order to reduce the vulnerability to such maliciously transmitted
Registration Reply messages with the unauthenticated extension, the
mobile node MAY delay processing of such denied Registration Reply
messages for a short while in order to determine whether another
successful Registration Reply might be received from the foreign
agent.
9. Acknowledgements
Thanks to Kent Leung and Henrik Lefkowetz for suggested improvements
to this specification.
10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Glass, S. and M. Chandra, "Registration Revocation in Mobile
IPv4", RFC 3543, August 2003.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
Author's Address
Charles E. Perkins
Palo Alto Systems Research Lab
Nokia Research Center
975 Page Mill Road, Suite 200
Palo Alto, CA 94304-1003
Phone: +1 650-496-4402
Fax: +1-650-739-0779
EMail: charles.perkins@nokia.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).
AI ELI5
On this page
§1The Problem With Foreign Agent Status
In Mobile IPv4 (RFC 3344), a mobile node registers through a foreign agent and the reply comes back from its home agent. The home agent authenticates its reply, so the mobile node can check that it really came from the home agent.
The trouble, as the abstract puts it, is that a foreign agent cannot supply status information without destroying the mobile node's ability to verify that authentication data. RFC 4636 fixes this by giving the foreign agent a better place to put its status: a new extension that does not disturb what the home agent supplied.
A helper in the middle sometimes needs to say something about your message. Before, the only way was to change the message itself, which spoiled the proof of who wrote it.
§3The FA Error Extension Format
The FA Error Extension follows the Short Extension format of Mobile IPv4 and is not skippable. It has four one-byte fields: Type (45), Length (2), Sub-Type (0) and Status.
The Status field carries a status code that the foreign agent uses to give status information to the mobile node.
It is a tiny four-part note: what kind of note it is, how long it is, a sub-label, and the actual code saying what went wrong.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 45 | Identifies the extension. |
LENGTH | Length | 1 byte | 2 | Length value for this extension. |
SUB-TYPE | Sub-Type | 1 byte | 0 | Sub-type within this extension type. |
STATUS | Status | 1 byte | Status code supplied by the foreign agent. |
§4Where and How It Is Used
The extension is valid only inside Mobile IPv4 Registration Reply messages. Because it is not skippable, a mobile node that cannot correctly interpret it MUST NOT use the care-of address from the reply until it has sent another Registration Request and received a successful Registration Reply.
Allowed status codes are in the range 64-127. The RFC lists the currently specified ones, as defined in RFC 3344 for foreign agent use. Codes for this extension must not be defined differently for the Code field of Registration Reply messages.
When a foreign agent appends the extension to a reply received from the home agent, it has to update the UDP Length field in the UDP header to account for the extra 4 bytes.
This RFC updates RFC 3344. When the home agent fails authentication, the foreign agent used to change the reply's status field to 68. Now it should append the FA Error Extension containing status value 68.
The note can only ride along on a reply. If you cannot read the note, you must not trust the new address until you ask again and get a good answer.
- 64reason unspecified — No specific reason given.
- 65administratively prohibited — Refused for administrative reasons.
- 66insufficient resources — The foreign agent lacks resources.
- 68home agent failed authentication — Now reported through this extension.
- 71poorly formed Reply — The reply was malformed.
- 77invalid care-of address — The care-of address is not valid.
- 78registration timeout — The registration timed out.
§5Mobile Node and Foreign Agent Behavior
If a mobile node receives a successful Registration Reply (status code 0 or 1) with an FA Error Extension saying the foreign agent is not honoring that reply, the mobile node SHOULD send a deregistration message to the home agent. That keeps the home agent from holding a registration that disagrees with the foreign agent's.
When a foreign agent denies a successful Registration Reply, it SHOULD send a Registration Revocation message (RFC 3543) to the home agent, if a mobility security association exists between them.
If the helper says it will not pass your message on, you tell your home base to forget it. The helper can also tell home base itself, if they trust each other.
§7Number Allocations
The RFC reserves one number for the extension from the space of non-skippable mobility extensions (0-127) defined for Mobile IPv4. It also creates a new number space of sub-types for this extension type, with sub-type zero allocated to this extension. Future allocations from it require expert review.
The status codes allowed in the extension are a subset of those in RFC 3344. If new Mobile IPv4 status codes are defined later, each definition must say whether the code may be used in the FA Error Extension.
The RFC asks for one official number for its note type and starts a fresh list of sub-labels, where it takes the first spot.
§8Security Considerations
The extension improves Mobile IPv4 security because the mobile node can be sure of the authenticity of the home agent's data while still receiving the foreign agent's status.
The extension itself is unauthenticated, though. Often the mobile node has no security association with the foreign agent, so it cannot tell that the foreign agent sending the extended reply is the one that received its request. A malicious foreign agent could make the mobile node act as if registration had failed even though the home agent and a correct foreign agent accepted it. To reduce that risk, the mobile node MAY delay processing such denied replies for a short while to see whether a successful reply arrives from the foreign agent.
Anyone in the middle could write a fake 'it failed' note. So the mobile node may wait a moment in case a real success message shows up.