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.
























Perkins                     Standards Track                     [Page 1]

RFC 4636                   FA Error Extension               October 2006


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.





Perkins                     Standards Track                     [Page 2]

RFC 4636                   FA Error Extension               October 2006


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.





Perkins                     Standards Track                     [Page 3]

RFC 4636                   FA Error Extension               October 2006


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



Perkins                     Standards Track                     [Page 4]

RFC 4636                   FA Error Extension               October 2006


  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: [email protected]









Perkins                     Standards Track                     [Page 5]

RFC 4636                   FA Error Extension               October 2006


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
  [email protected].

Acknowledgement

  Funding for the RFC Editor function is provided by the IETF
  Administrative Support Activity (IASA).







Perkins                     Standards Track                     [Page 6]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.