draft-ietf-geopriv-flow-identity-01.txt   draft-ietf-geopriv-flow-identity-02.txt 
GEOPRIV R. Bellis GEOPRIV R. Bellis
Internet-Draft Nominet UK Internet-Draft Nominet UK
Updates: RFC 6155 (if approved) February 13, 2013 Updates: RFC 6155 (if approved) March 1, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: August 17, 2013 Expires: September 2, 2013
Flow Identity Extension for HELD Flow Identity Extension for HELD
draft-ietf-geopriv-flow-identity-01 draft-ietf-geopriv-flow-identity-02
Abstract Abstract
RFC 6155 specifies an extension for the HTTP-Enabled Location RFC 6155 specifies an extension for the HTTP-Enabled Location
Delivery (HELD) Protocol allowing the use of an IP address and port Delivery (HELD) Protocol allowing the use of an IP address and port
number to request a Device location based on an individual packet number to request a Device location based on an individual packet
flow. flow.
However, certain kinds of NAT require that identifiers for both ends However, certain kinds of NAT require that identifiers for both ends
of the packet flow must be specified in order to unambiguously of the packet flow must be specified in order to unambiguously
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2013. This Internet-Draft will expire on September 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
requests for target Devices that are behind a NAT device. requests for target Devices that are behind a NAT device.
Subsequent analysis has determined that in the presence of particular Subsequent analysis has determined that in the presence of particular
types of NAT device, and in particular Carrier Grade NATs, it is types of NAT device, and in particular Carrier Grade NATs, it is
necessary to know the complete tuple of (layer 3 protocol, layer 4 necessary to know the complete tuple of (layer 3 protocol, layer 4
protocol, source address, source port, destination address, protocol, source address, source port, destination address,
destination port) in order to unambiguously identify a flow, and destination port) in order to unambiguously identify a flow, and
therefore the true target Device. therefore the true target Device.
This document specifies an XML Schema and URN Sub-Namespace for a This document specifies an XML Schema and URN Sub-Namespace for a
Flow Identity Extension to support this requirement. Flow Identity Extension to support this requirement and provides a
more generally applicable means of identifying a Device based on the
parameters of a network flow of which it is an endpoint.
Since the Location Recipient may not know in advance whether the Since the Location Recipient may not know in advance whether the
Target is behind a NAT device the port number elements from Section Target is behind a NAT device the port number elements from Section
3.3 of [RFC6155] are deprecated and MUST NOT be used. This document 3.3 of [RFC6155] are deprecated and MUST NOT be used in new client
provides a more generally applicable means of identifying a Device implementations. Note that server implementations of this
based on the parameters of a network flow of which it is an endpoint. specification may still encounter requests formed by clients that
have implemented only [RFC6155] and those requests might contain the
deprecated port element.
For implementation details not specified in this document please
refer to [RFC6155] and [RFC5985].
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Usage 3. Usage
An example HELD request is shown below: An example HELD request is shown below:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8"> responseTime="8">
<locationType exact="true">geodetic</locationType> <locationType exact="true">geodetic</locationType>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow" <flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4"> layer4="tcp" layer3="ipv4">
<src> <src>
<address>192.168.1.1</address> <address>192.0.2.25</address>
<port>1024</port> <port>1024</port>
</src> </src>
<dst> <dst>
<address>10.0.0.1</address> <address>198.51.100.238</address>
<port>80</port> <port>80</port>
</dst> </dst>
</flow> </flow>
</locationRequest> </locationRequest>
The <flow> element MUST contain: The <flow> element MUST contain:
o a "layer3" attribute with a value of "ipv4" or "ipv6". o a "layer3" attribute with a value of "ipv4" or "ipv6".
o a "layer4" attribute with a value of "udp" [RFC0768], "tcp" o a "layer4" attribute with a value of "udp" [RFC0768], "tcp"
[RFC0793], "sctp" [RFC4960], "dccp" [RFC4340], or a decimal [RFC0793], "sctp" [RFC4960], "dccp" [RFC4340], or a decimal
integer representing any applicable protocol from the IANA integer representing any applicable protocol from the IANA
Assigned Internet Protocol Numbers Registry. Assigned Internet Protocol Numbers Registry.
o a <src> element and a <dst> element whose child elements contain
the layer 3 address (which MUST conform to the relevant
"IPv4address" or "IPv6address" grammar as defined in [RFC3986])
and the layer 4 port number of each end of the flow.
and MAY optionally contain: and MAY optionally contain:
o a "target" attribute with a value of "src" (default) or "dst" to o a "target" attribute with a value of "src" (default) or "dst" to
indicate which end of the flow is the Target of the indicate which end of the flow is the Target of the
<locationRequest> with respect to the HELD protocol. <locationRequest> with respect to the HELD protocol.
4. XML Schema 4. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv:held:flow" <xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv:held:flow"
skipping to change at page 9, line 7 skipping to change at page 9, line 7
URI: urn:ietf:params:xml:ns:geopriv:held:flow URI: urn:ietf:params:xml:ns:geopriv:held:flow
Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org),
Ray Bellis (ray.bellis@nominet.org.uk) Ray Bellis (ray.bellis@nominet.org.uk)
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 4 of this document. Section 4 of this document.
6. Privacy Considerations 6. Privacy Considerations
This document introduces no new privacy considerations beyond those All of the considerations in [RFC6155] apply to the use of the
in [RFC6155] mechanism defined in this document. Like [RFC6155], this
specification assumes that the Location Server being queried already
has access to the internal state of the network near one end of the
flow being queried (for instance, access to the bindings in a NAT in
the path of the flow). Clients making queries using this
specification in environments where that assumption may not be true
should be aware that the request provides information about that
client's communications that the Location Server would not otherwise
be able to discern and may represent additional privacy exposure for
that client.
7. Security Considerations 7. Security Considerations
This document introduces no new security considerations beyond those This document introduces no new security considerations beyond those
in [RFC6155] in [RFC6155]
8. Acknowledgements 8. Acknowledgements
The author wishes to thank the members of the NICC Emergency Location The author wishes to thank the members of the NICC Emergency Location
Task Group, the IETF GeoPriv Working Group, and the authors of Task Group, the IETF GeoPriv Working Group, and the authors of
skipping to change at page 13, line 15 skipping to change at page 13, line 15
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011. Delivery (HELD)", RFC 6155, March 2011.
10.2. Informative References 10.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
 End of changes. 11 change blocks. 
12 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/