idnits 2.17.1 draft-ietf-geopriv-flow-identity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2013) is 4074 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 informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. Bellis 3 Internet-Draft Nominet UK 4 Updates: RFC 6155 (if approved) March 1, 2013 5 Intended status: Standards Track 6 Expires: September 2, 2013 8 Flow Identity Extension for HELD 9 draft-ietf-geopriv-flow-identity-02 11 Abstract 13 RFC 6155 specifies an extension for the HTTP-Enabled Location 14 Delivery (HELD) Protocol allowing the use of an IP address and port 15 number to request a Device location based on an individual packet 16 flow. 18 However, certain kinds of NAT require that identifiers for both ends 19 of the packet flow must be specified in order to unambiguously 20 satisfy the location request. 22 This document specifies an XML Schema and URN Sub-Namespace for a 23 Flow Identity Extension for HELD to support this requirement. 25 This document updates RFC 6155 by deprecating the port number 26 elements specified therein. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 2, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . 4 64 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. URN Sub-Namespace Registration for 68 urn:ietf:params:xml:ns:geopriv:held:flow . . . . . . . . . 8 69 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 8 70 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Notes to the RFC Editor (to be removed) . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Work at the Emergency Location Task Group of NICC Standards Ltd (the 82 UK's telecoms industry standards body) prompted the addition of Port 83 Number identifiers in HELD Identity [RFC6155] to allow HELD [RFC5985] 84 requests for target Devices that are behind a NAT device. 86 Subsequent analysis has determined that in the presence of particular 87 types of NAT device, and in particular Carrier Grade NATs, it is 88 necessary to know the complete tuple of (layer 3 protocol, layer 4 89 protocol, source address, source port, destination address, 90 destination port) in order to unambiguously identify a flow, and 91 therefore the true target Device. 93 This document specifies an XML Schema and URN Sub-Namespace for a 94 Flow Identity Extension to support this requirement and provides a 95 more generally applicable means of identifying a Device based on the 96 parameters of a network flow of which it is an endpoint. 98 Since the Location Recipient may not know in advance whether the 99 Target is behind a NAT device the port number elements from Section 100 3.3 of [RFC6155] are deprecated and MUST NOT be used in new client 101 implementations. Note that server implementations of this 102 specification may still encounter requests formed by clients that 103 have implemented only [RFC6155] and those requests might contain the 104 deprecated port element. 106 For implementation details not specified in this document please 107 refer to [RFC6155] and [RFC5985]. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Usage 117 An example HELD request is shown below: 119 121 geodetic 122 124 125
192.0.2.25
126 1024 127 128 129
198.51.100.238
130 80 131 132 133 135 The element MUST contain: 137 o a "layer3" attribute with a value of "ipv4" or "ipv6". 139 o a "layer4" attribute with a value of "udp" [RFC0768], "tcp" 140 [RFC0793], "sctp" [RFC4960], "dccp" [RFC4340], or a decimal 141 integer representing any applicable protocol from the IANA 142 Assigned Internet Protocol Numbers Registry. 144 o a element and a element whose child elements contain 145 the layer 3 address (which MUST conform to the relevant 146 "IPv4address" or "IPv6address" grammar as defined in [RFC3986]) 147 and the layer 4 port number of each end of the flow. 149 and MAY optionally contain: 151 o a "target" attribute with a value of "src" (default) or "dst" to 152 indicate which end of the flow is the Target of the 153 with respect to the HELD protocol. 155 4. XML Schema 157 158 163 164 166 HELD Flow Identity 167 169 This document defines Flow Identity elements for HELD. 170 171 173 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 220 5. IANA Considerations 222 5.1. URN Sub-Namespace Registration for 223 urn:ietf:params:xml:ns:geopriv:held:flow 225 This section registers a new XML namespace, 226 "urn:ietf:params:xml:ns:geopriv:held:flow", as per the guidelines in 227 [RFC3688]. 229 URI: urn:ietf:params:xml:ns:geopriv:held:flow 231 Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), 232 Ray Bellis (ray.bellis@nominet.org.uk) 234 XML: 236 BEGIN 237 238 240 241 242 HELD Flow Identity Parameters 243 244 245

Namespace for HELD Flow Identity Parameters

246

urn:ietf:params:xml:ns:geopriv:held:flow

247

See 248 RFC NEW1.

249 250 251 END 253 5.2. XML Schema Registration 255 This section registers an XML schema as per the guidelines in 256 [RFC3688] 258 URI: urn:ietf:params:xml:ns:geopriv:held:flow 260 Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), 261 Ray Bellis (ray.bellis@nominet.org.uk) 263 Schema: The XML for this schema can be found as the entirety of 264 Section 4 of this document. 266 6. Privacy Considerations 268 All of the considerations in [RFC6155] apply to the use of the 269 mechanism defined in this document. Like [RFC6155], this 270 specification assumes that the Location Server being queried already 271 has access to the internal state of the network near one end of the 272 flow being queried (for instance, access to the bindings in a NAT in 273 the path of the flow). Clients making queries using this 274 specification in environments where that assumption may not be true 275 should be aware that the request provides information about that 276 client's communications that the Location Server would not otherwise 277 be able to discern and may represent additional privacy exposure for 278 that client. 280 7. Security Considerations 282 This document introduces no new security considerations beyond those 283 in [RFC6155] 285 8. Acknowledgements 287 The author wishes to thank the members of the NICC Emergency Location 288 Task Group, the IETF GeoPriv Working Group, and the authors of 289 [RFC6155], from which the text for the URN and XML Schema 290 Registrations were derived. 292 9. Notes to the RFC Editor (to be removed) 294 References to "NEW1" need to be replaced with this document's final 295 RFC number. 297 10. References 299 10.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 305 January 2004. 307 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 308 Resource Identifier (URI): Generic Syntax", STD 66, 309 RFC 3986, January 2005. 311 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 312 RFC 5985, September 2010. 314 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 315 Barnes, "Use of Device Identity in HTTP-Enabled Location 316 Delivery (HELD)", RFC 6155, March 2011. 318 10.2. Informative References 320 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 321 August 1980. 323 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 324 RFC 793, September 1981. 326 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 327 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 329 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 330 RFC 4960, September 2007. 332 Author's Address 334 Ray Bellis 335 Nominet UK 336 Edmund Halley Road 337 Oxford OX4 4DQ 338 United Kingdom 340 Phone: +44 1865 332211 341 Email: ray.bellis@nominet.org.uk 342 URI: http://www.nominet.org.uk/