idnits 2.17.1 draft-ietf-mip4-faerr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 257. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 September 2005) is 6791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (ref. '4') (Obsoleted by RFC 5944) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 20 September 2005 5 Foreign Agent Error Extension for Mobile IPv4 6 draft-ietf-mip4-faerr-02.txt 8 Status of This Memo 10 This document is a submission by the IETF MIPv4 Working Group Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the mip4@ietf.org mailing list. 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note 21 that other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document specifies a new extension for use by Foreign Agents 38 operating Mobile IP for IPv4. Currently, a foreign agent cannot 39 supply status information without destroying the ability for a mobile 40 node to verify authentication data supplied by the home agent. The 41 new extension solves this problem by making a better place for the 42 foreign agent to provide its status information to the mobile node. 44 1. Introduction 46 This document specifies a new non-skippable extension for use 47 by Foreign Agents operating Mobile IP for IPv4 [4]. The new 48 extension option allows a foreign agent to supply an error code 49 without disturbing the data supplied by the Home Agent within the 50 Registration Reply message. In this way, the mobile node can verify 51 that the Registration Reply message was generated by the Home Agent 52 even in cases where the foreign agent is required by protocol to 53 insert new status information into the Registration Reply message. 55 2. Terminology 57 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [1]. Other 60 terminology is used as already defined in [4]. 62 3. FA Error Extension Format 64 The format of the FA Error Extension conforms to the Short Extension 65 format specified for Mobile IPv4 [4]. The FA Error Extension is not 66 skippable. 68 0 1 2 3 69 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 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Type | Length | Sub-Type | Status | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 Type 76 78 Length 80 2 82 Sub-Type 84 0 86 Status 88 A status code used by the foreign agent to supply status 89 information to the mobile node. 91 4. Operation and Use of the FA Error Extension 93 The FA Error extension is only valid for use within Mobile IPv4 94 Registration Reply messages. The FA Error Extension is not 95 skippable. A mobile node that cannot correctly interpret the 96 contents of the FA Error Extension MUST NOT use the care-of 97 address provided in the Registration Reply message, until another 98 Registration Request message has been sent and a successful 99 Registration Reply message received. 101 Status codes allowable for use within the FA Error Extension are 102 within the range 64-127. The currently specified codes are as 103 follows: 105 64 reason unspecified 106 65 administratively prohibited 107 66 insufficient resources 108 68 home agent failed authentication 109 71 poorly formed Reply 110 77 invalid care-of address 111 78 registration timeout 113 as defined in RFC 3344 [4] for use by the Foreign Agent. Status 114 codes for use with the FA Error extensions must not be differently 115 defined for use in the Code field of Registration Reply messages. 117 When a foreign agent appends a FA Error Extension to the Registration 118 Reply as received from the Home Agent, it has to update the UDP 119 Length field in the UDP header [5] to account for the extra 4 bytes 120 of length. 122 This document updates the Mobile IP base specification [4] regarding 123 the procedures followed by the foreign agent in the case that the 124 home agent fails authentication. Instead of modifying the "status" 125 field of the Registration Reply to contain the value 68, now the 126 foreign agent should append the Foreign Agent Error Extension 127 containing the status value 68. 129 5. Mobile Node Considerations 131 If a mobile node receives a successful Registration Reply (status 132 code 0 or 1), with a FA Error extension indicating that the foreign 133 agent is not honoring said Registration Reply, the mobile node SHOULD 134 then send a deregistration message to the home agent. In this way, 135 the home agent will not maintain a registration status that is 136 inconsistent with the status maintained by the foreign agent. 138 6. Foreign Agent Considerations 140 When denying a successful Registration Reply, the Foreign Agent 141 SHOULD send the a Registration Revocation message [2] to the Home 142 Agent if a mobility security association exists between them. 143 For cases when the foreign agent does have the required security 144 association, this way of informing the home agent does not have the 145 vulnerability from detrimental actions by malicious foreign agents as 146 noted in section 8. 148 7. IANA Considerations 150 This specification reserves one number for the FA Error extension 151 (see section 3) from the space of numbers for non-skippable mobility 152 extensions (i.e., 0-127) defined in the specification for Mobile 153 IPv4 [4]. 155 This specification also creates a new number space of sub-types for 156 the type number of this extension. Sub-type zero is to be allocated 157 from this number space for the protocol extension specified in this 158 document. Similar to the procedures specified for Mobile IP [4] 159 number spaces, future allocations from this number space require 160 expert review[3]. 162 The status codes which are allowable in the FA error extension are a 163 subset of the status codes defined in the specification for Mobile 164 IPv4 [4]. If, in the future, additional status codes are defined for 165 Mobile IPv4, the definition for each new status code must indicate 166 whether or not the new status code is allowable for use in the FA 167 Error extension. 169 8. Security Considerations 171 The extension in this document improves the security features 172 of Mobile IPv4 by allowing the mobile node to be assured of the 173 authenticity of the information supplied within a Registration 174 Request. Previously, whenever the foreign agent was required to 175 provide status information to the mobile node, it could only do so by 176 destroying the ability of the mobile device to verify the Mobile-Home 177 Authentication Extension data. 179 In many common cases, the mobile node will not have a security 180 association with the foreign agent that has sent the extension. 181 Thus, the mobile node will be unable to ascertain that the foreign 182 agent sending the extended Registration Reply message is the same 183 foreign agent that earlier received the associated Registration 184 Request from the mobile node. Because of this, a malicious foreign 185 agent could cause a mobile node to operate as if the registration had 186 failed, when in fact its home agent and a correctly operating foreign 187 agent had both accepted the mobile node's Registration Request. In 188 order to reduce the vulnerability to such maliciously transmitted 189 Registration Reply messages with the unauthenticated extension, the 190 mobile node MAY delay processing of such denied Registration Reply 191 messages for a short while in order to determine whether another 192 successful Registration Reply might be received from the foreign 193 agent. 195 9. Acknowledgements 197 Thanks to Kent Leung and Henrik Lefkowetz for suggested improvements 198 to this specification. 200 References 202 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 203 Levels. RFC 2119, Internet Engineering Task Force, March 1997. 205 [2] S. Glass and Madhavi Chandra. Registration Revocation in Mobile 206 IPv4. RFC 3543, Internet Engineering Task Force, August 2003. 208 [3] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 209 Considerations Section in RFCs. RFC 2434, Internet Engineering 210 Task Force, October 1998. 212 [4] Charles E. Perkins. IP Mobility Support for IPv4. RFC 3344, 213 Internet Engineering Task Force, August 2002. 215 [5] J. B. Postel. User Datagram Protocol. RFC 768, Internet 216 Engineering Task Force, August 1980. 218 All references are normative. 220 Author Address 222 Questions about this memo can be directed to the author: 224 Charles E. Perkins 225 Networking Technology Lab 226 Nokia Research Center 227 313 Fairchild Drive 229 Mountain View, California 94043 230 USA 231 Phone: +1-650 625-2986 232 Fax: +1 650 625-2502 233 EMail: charles.perkins@.nokia.com 235 Intellectual Property Statement 237 The IETF takes no position regarding the validity or scope of any 238 Intellectual Property Rights or other rights that might be claimed to 239 pertain to the implementation or use of the technology described in 240 this document or the extent to which any license under such rights 241 might or might not be available; nor does it represent that it has 242 made any independent effort to identify any such rights. Information 243 on the procedures with respect to rights in RFC documents can be 244 found in BCP 78 and BCP 79. 246 Copies of IPR disclosures made to the IETF Secretariat and any 247 assurances of licenses to be made available, or the result of an 248 attempt made to obtain a general license or permission for the 249 use of such proprietary rights by implementers or users of this 250 specification can be obtained from the IETF on-line IPR repository at 251 http://www.ietf.org/ipr. 253 The IETF invites any interested party to bring to its attention any 254 copyrights, patents or patent applications, or other proprietary 255 rights that may cover technology that may be required to implement 256 this standard. Please address the information to the IETF at 257 ietf-ipr@ietf.org. 259 Disclaimer of Validity 261 This document and the information contained herein are provided 262 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 263 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 264 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 265 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 266 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 267 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 269 Copyright Statement 271 Copyright (C) The Internet Society (2005). This document is subject 272 to the rights, licenses and restrictions contained in BCP 78, and 273 except as set forth therein, the authors retain all their rights.