idnits 2.17.1 draft-carlberg-ets-mip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** Bad filename characters: the document name given in the document, 'draft-carlberg-ets-MIP-00', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-carlberg-ets-MIP-00', but the file name used is 'draft-carlberg-ets-mip-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 79 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '...d is in full ...' == Line 18 has weird spacing: '...ay also distr...' == Line 20 has weird spacing: '...ents at any...' == Line 21 has weird spacing: '...me. It is i...' == Line 24 has weird spacing: '... The list ...' == (74 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 155 looks like a reference -- Missing reference section? '3' on line 118 looks like a reference -- Missing reference section? '4' on line 166 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ken Carlberg 3 INTERNET DRAFT G11 4 May 14, 2004 Charlie Perkins 5 Nokia 7 Requirements for MIPv4 Mobility Agents 8 Support of Emergency Telecommunication Service 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document presents a list of requirements for the IPv4 Mobile IP 35 (MIP) protocol to support Emergency Telecommunications Service (ETS). 37 1. Introduction 39 Effective telecommunications capabilities can be imperative to 40 facilitate immediate recovery operations for serious disaster events, 41 such as, hurricanes, floods, earthquakes, and attacks by hostile 42 individuals. Disasters can happen any time, any place, unexpectedly. 43 Quick response for recovery operations requires immediate access to 44 any public telecommunications capabilities at hand. These 45 capabilities include: conventional telephone, cellular phones, and 46 Internet access (possibly at 802.11 hotspots) via online terminals, 47 IP telephones, and wireless PDAs. The commercial telecommunications 48 infrastructure is rapidly evolving to Internet-based technology. 49 Therefore, the Internet community should accept the responsibility to 50 consider how it can best support emergency management and recovery 51 operations. 53 Emergency Telecommunications Service (ETS) involves authorized access 54 and use of services (i.e., resources) set aside for users involved in 55 disaster response or recovery. The manner in which these resources 56 are identified and allocated for ETS users is outside the scope of 57 this document. 59 A general set of requirements for ETS has been defined in [2], and is 60 meant to act as a baseline for future and more specific requirements. 61 The requirements presented in section 3 below represent an extension 62 to [2] and are aimed at the mobility agents specified in the Mobile 63 IP (MIP) protocol [3]. 65 Note, all references to MIP in this document refer to the IPv4 66 version of the protocol. However, similar considerations can be 67 expected to be applied for IPv6 MIP whenever the appropriate access 68 control points are able to be identified. For IPv4, it is easy to 69 specify the foreign agent as the requisite control point. 71 2. Mobile IP 73 MIP is used to support a mobile host that operates in either its home 74 or in foreign networks. These networks have mobility agents, 75 designated as either foreign agents or home agents, that forward 76 traffic between the mobile device and correspondent hosts. Agent 77 Discovery involves an exchange of messages (Agent Advertisements) 78 that allow the mobile host to determine whether it is connected 79 within its home domain or in a foreign network. This discovery 80 process also indicates if the host has moved to a different IP 81 network. 83 Beyond the discovery of other MIP nodes and movement, Agent 84 Advertisements are used by mobility agents to advertise services on a 85 link. These messages are sent as an extension of the ICMP Router 86 Advertisement. The Mobility Agent Advertisement Extension message is 87 an example of the extentions defined in MIP and is used to convey one 88 of several services that are offered by the node -- such as "this 89 node is a Home Agent and/or Foreign Agent". Of particular importance 90 to this document is that this extension may indicate that the Foreign 91 Agent is BUSY and will not accept registrations from additional 92 mobile nodes. 94 The existance of a busy condition implies that a threshold exists 95 that prevents any additional registrations to be accepted by that 96 mobility agent. During times of disasters, a need may arise to allow 97 mobile users involved in disaster recovery or response to bypass this 98 "busy" condition. This function, and the requirements of how it is 99 accomplished, is the concern of this document. The precise manner in 100 which this bypass is accomplished with respect to conveying existing 101 and requested service is outside the scope of this document. 102 However, contraints and references to previous related RFCs with 103 respect to security are listed. 105 3. Requirements 107 We divide the set of requirements into two subgroups. The first 108 involves the list of requirements concerning the advertisement of ETS 109 support and the request/registration of that service. The second set 110 of requirements pertain to security and the authorization & 111 authentication features needed by the system to ensure that the 112 correct set of users are enabled to obtain their desired service. 114 3.1 Conveying ETS Information 116 The requirements below pertain to those entities that choose to 117 support ETS type users. For those that choose not to provide this 118 support users, either because of legacy implementations of [3] or 119 because of lack of configuration, the following do not apply. 121 3.1.1 Mobility Agent Indicates ETS Support 123 In order for mobile hosts to determine if ETS type users are 124 supported, mobility agents are required to be able to advertise this 125 service and therefore distinguish themselves from other mobility 126 agents. 128 3.1.2 Form of ETS Advertisement by Mobility Agent 130 The advertisement of ETS support by mobility agents can either be a 131 binary indicator, or a more descriptive format that identifies the 132 sets of ETS users supported by that agent. Tradeoffs regarding 133 scarcity of unreserved fields in existing MIP messages versus 134 significant changes to MIP deserve close consideration. 136 3.1.3 Role of Mobility Agents 138 Mobility Agents may support non-ETS users at the same time as 139 providing support for ETS users. 141 3.1.4 Mobile Host Requesting ETS Support 143 If a mobile host needs to use an ETS capable mobility agent, the 144 means by which a mobile host obtains that service has to be specified 145 -- this is particularly important when mobile agents support for ETS 146 and non-ETS users. This is likely to involve defining a new message 147 format that explicitly signals the requested service, but it may also 148 involve others means of identification. 150 3.1.5 Preemption 152 Mobility agents that provide ETS support may preempt (or even 153 terminate) existing registrations of non-ETS users in favor of ETS 154 users. This action is subject to local policies of that agent. 155 Refer to [2] for additional insight in the role of policies with 156 respect to ETS. 158 3.2 Security Requirements 160 The operation of ETS is expected to introduce certain security 161 requirements, which are mentioned in this section. 163 3.2.1 MIP AAA compatibility 165 Solutions are expected to remain compatible with the MIP AAA 166 requirements document of RFC 2977[4]. 168 3.2.2 Foreign agent operation 170 Foreign agents are required to be able to check that a mobile device 171 is authorized to use ETS. Otherwise, arbitrary mobile devices could 172 routinely obtain services for applications that have no requirement 173 for emergency services. 175 4. Security Considerations 177 If a foreign agent does not protect against unauthorized invocation 178 of ETS features, the danger exists that the additional resources 179 required would be unavailable in the case of real need. Moreover, a 180 malicious node would typically target ETS to disable the delivery of 181 needed support in conflict situations. Vulnerability to such attacks 182 should be minimized. 184 5. References 186 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 187 9, RFC 2026, October 1996. 189 2 Carlberg, K., Atkinson, R., "General Requirements for Emergency 190 Telecommunication Service (ETS)", RFC 3689, February 2004 192 3 Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, 193 August 2002. 195 4 Glass, S., et. al, "Mobile IP Authentication, Authorization, 196 and Accounting Requirements", RFC 2977, October 2000 198 6. Author's Addresses 200 Ken Carlberg Charlie Perkins 201 G11 Communications Systems Laboratory 202 123a Versailles Circle Nokia Research Center 203 Baltimore, MD 313 Fairchild Drive 204 USA Mountain View, CA 94303 205 USA 206 carlberg@g11.org.uk Charles.Perkins@nokia.com 208 Full Copyright Statement 210 "Copyright (C) The Internet Society (2004). All Rights Reserved. 211 This document and translations of it may be copied and furnished to 212 others, and derivative works that comment on or otherwise explain it 213 or assist in its implementation may be prepared, copied, published 214 and distributed, in whole or in part, without restriction of any 215 kind, provided that the above copyright notice and this paragraph are 216 included on all such copies and derivative works. However, this 217 document itself may not be modified in any way, such as by removing 218 the copyright notice or references to the Internet Society or other 219 Internet organizations, except as needed for the purpose of 220 developing Internet standards in which case the procedures for 221 copyrights defined in the Internet Standards process must be 222 followed, or as required to translate it into languages other than 223 English. 225 The limited permissions granted above are perpetual and will not be 226 revoked by the Internet Society or its successors or assigns. 228 This document and the information contained herein is provided as an 229 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 230 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 231 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 232 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 233 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.