--- 1/draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt 2013-01-28 07:15:19.911707514 +0100 +++ 2/draft-ietf-geopriv-dhcp-lbyr-uri-option-16.txt 2013-01-28 07:15:19.939708648 +0100 @@ -1,328 +1,384 @@ + Network WG James Polk Internet-Draft Cisco Systems -Intended status: Proposed Standard May 31, 2012 -Expires: Nov 30, 2012 +Intended status: Proposed Standard Jan 27, 2013 +Expires: June 27, 2013 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) - draft-ietf-geopriv-dhcp-lbyr-uri-option-15 + draft-ietf-geopriv-dhcp-lbyr-uri-option-16 Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource - Identifier (URI). This Location URI can then be dereferenced in a - separate transaction by the client or sent to another entity and - dereferenced to learn physically where the client is located. + Identifier (URI), and another Option to explicitly indicate how long + that location URI is to be considered valid. This Location URI can + then be dereferenced in a separate transaction by the client or sent + to another entity and dereferenced to learn physically where the + client is located, but only while valid. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 30, 2012. + This Internet-Draft will expire on June 27, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Format of the DHCP LocationURI Option . . . . . . . . . . . . 4 + 2. Format of the DHCP LocationURI and Valid-For Options . . . . 4 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5 - 2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5 + 2.3. Overall Format of Valid-For Option in IPv4 . . . . . . 5 + 2.4. Overall Format of Valid-For Option in IPv6 . . . . . . 6 + 2.5. Rules for both LocationURI and Valid-For Options . . . 6 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource - Identifier (URI). The DHCP implementation of the client can then - make this location information available to upper layer protocols - for their usage. This location URI points a Location Server - [RFC5808] which has the geolocation of the client (through means - not defined in this document). In this scenario, the DHCP client - is a Geopriv Target (i.e., the entity whose geolocation is - associated with the location URI). - - Applications using upper layer protocols within the Target can then - choose to deference this location URI and/or transmit the URI to - another entity as a means of conveying where the Target is located. - Dereferencing a location URI is described in [RFC6442]. Conveying - a location URI is also described in [RFC6442]. Session Initiation - Protocol (SIP) is not the only protocol that can dereference a - location URI; there is also HTTP-Enabled Location Delivery (HELD) - [ID-HELD-DEREF] and HTTP [RFC2616]. + Identifier (URI), and another Option to explicitly indicate how long + that location URI is to be considered valid. In this scenario, the + DHCP client is a Geopriv Target (i.e., the entity whose geolocation + is associated with the location URI). The DHCP implementation of the + client can then make this location information available to other + applications for their usage. This location URI points a Location + Server [RFC5808] which has the geolocation of the client (e.g., + uploaded into a wiremap database when the client attached wall-jack, + or by means of 802.11 geolocation mechanisms). - Having a location URI has advantages over having a PIDF-LO, - especially when a target's location changes. With a location URI, - when a target moves, the location URI does not change (at least - within the same domain). It can still be given out as the reference - to the Target's current location. The opposite is true if the - location is conveyed by value in a message. Once the Target moves, - the previously given location is no longer valid, and if the Target - wants to inform another entity about its location, it has to send - the PIDF-LO to the location recipient (again). + Applications within the Target can then choose to deference this + location URI and/or transmit the URI to another entity as a means of + conveying where the Target is located. Both Conveying and + Dereferencing a location URI is described in [RFC6442]. Session + Initiation Protocol (SIP) is not the only protocol that can + dereference a location URI; there is also HTTP-Enabled Location + Delivery (HELD) [ID-HELD-DEREF] and HTTP [RFC2616]. A Location Server (LS) stores the Target's location as a presence document, called a Presence Information Data Format - Location Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server is the entity contacted during the act of dereferencing a Target's location. If the dereferencing entity has permission, defined in [ID-GEO-POL], the location of the target will be received. The LS - will grant permission to location inquires based on the rules + will grant permission to location inquiries based on the rules established by a Rule Holder [RFC3693]. The LS has the ability to challenge any request for a target's location, thereby providing additive security properties before location revelation. + Possessing a location URI has advantages over having a PIDF-LO, + especially when a target's location changes. With a location URI, + when a target moves, the location URI does not change (at least + within the same domain). The location URI can still be given out as + the reference to the Target's current location. The opposite is true + if the location is conveyed by value in a message. Once the Target + moves, the previously given location is no longer valid, and if the + Target wants to inform another entity about its location, it has to + send the PIDF-LO to the location recipient (again). + A problem exists within existing RFCs that provide location to the - UA ([RFC6225] and [RFC4776]). These DHCP Options for geolocation + UA ([RFC6225] and [RFC4776]). Those DHCP Options for geolocation values require an update of the entire location information (LI) every time a client moves. Not all clients will move frequently, but some will. Refreshing location values every time a client moves does not scale in certain networks/environments, such as IP-based cellular networks, enterprise networks or service provider networks with mobile endpoints. An 802.11 based access network is one - example of this. Constantly updating LCI to endpoints might not - scale in mobile (residential or enterprise or municipal) networks in - which the client is moving through more than one network attachment - point, perhaps as a person walks or drives with their client down a + example of this. Constantly updating Location Configuration + Information (LCI) to endpoints might not scale in mobile + (residential or enterprise or municipal) networks in which the + client is moving through more than one network attachment point, + perhaps as a person walks or drives with their client down a neighborhood street or apartment complex or a shopping center or through a municipality (that has IP connectivity as a service). If the client was provided a location URI reference to retain and hand out when it wants or needs to convey its location (in a protocol other than DHCP), a location URI that would not change as - the client's location changes (within a domain), scaling issues + the client's location changes (within a domain).Scaling issues would be significantly reduced to needing an update of the location URI only when a client changes administrative domains - which is much less often. This delivery of an indirect location has the added benefit of not using up valuable or limited bandwidth to the client with the constant updates. It also relieves the client from having to determine when it has moved far enough to consider asking for a refresh of its location. In enterprise networks, if a known location is assigned to each individual Ethernet port in the network, a device that attaches to - the network a wall-jack (directly associated with a specific - Ethernet Switch port) will be associated with a known location via a - unique circuit-ID that's used by the RAIO Option defined in RFC 3046 - [RFC3046]. This assumes wall-jacks have an updated wiremap - database. RFC 6225 and RFC 4776 would return an LCI value of - location. This document specifies how a location URI is returned - using DHCP. The location URI points to a PIDF-LO contained on an - LS. Performing a dereferencing transaction, that Target's PIDF-LO - will be returned. If local configuration has the requirement of - only assigning unique location URIs to each client at the same - attachment point to the network (i.e., same RJ-45 jack or same - 802.11 Access Point - except when triangulation is used), then - unique location URIs will be given out, though they will all have - the same location at the record, relieving the backend Sighter or LS - from individually maintaining each location independently. + the network, such as a wall-jack (directly associated with a + specific Ethernet Switch port) will be associated with a known + location via a unique circuit-ID that's used by the Relay Agent + Information Option (RAIO) defined in RFC 3046 [RFC3046]. This + assumes wall-jacks have an updated wiremap database. RFC 6225 - This Option can be useful in IEEE 802.16e connected endpoints or IP - cellular endpoints. The location URI Option can be configured on a - router, such as a residential home gateway, such that the router - receives this Location URI Option as a client with the ability to - communicate to downstream endpoints as a server. + [RFC6225] and RFC 4776 [RFC4776] would return an LCI value of + location for either IPv4 or IPv6. This document specifies how a + location URI is returned using DHCP. The location URI points to a + PIDF-LO contained on an LS. Performing a dereferencing transaction, + that Target's PIDF-LO will be returned. If local configuration has + the requirement of only assigning unique location URIs to each + client at the same attachment point to the network (i.e., same RJ-45 + jack or same 802.11 Access Point - except when triangulation is + used), then unique location URIs will be given out. They will all + have the same location at the record, relieving the backend Sighter + or LS from individually maintaining each location independently. + + The location URI Option can be useful in IEEE 802.16e connected + endpoints or IP cellular endpoints. The location URI Option can be + configured on a router, such as a residential home gateway, such + that the router receives this Location URI Option as a client with + the ability to communicate to downstream endpoints as a server. How an LS responds to a dereference request can vary, and a policy established by a Ruleholder [RFC3693] for a Location Target as to what type of challenge(s) is to be used, how strong a challenge is used or how precise the location information is given to a Location Recipient (LR). This document does not provide mechanisms for the LS to tell the client about policies or for the client to specify a policy for the LS. While an LS should apply an appropriate access-control policy, clients must assume that the LS will provide location in response to any request (following the possession model [RFC5808]). For further discussion of privacy, see the Security Considerations. This document IANA-registers the new IPv4 and IPv6 DHCP Options for - a location URI. + a location URI and Valid-For. 2. Format of the DHCP LocationURI Option 2.1 Overall Format of LocationURI Option in IPv4 The LocationURI Option format for IPv4 is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code XXX | Length=XX | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . - . LocationURI... ... - . (see Section 2.3 for details) ... | + . LocationURI... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. IPv4 Fields for this LocationURI Option Code XXX: The code for this DHCPv4 option (IANA assigned). Length=XX: The length of this option, counted in bytes - not counting the Code and Length bytes. This is a variable length Option, therefore the length value will change based on the length of the URI within the Option. - LocationURI: see Section 2.3 for details + LocationURI: Location URI - This field, in bytes, is the URI + pointing at the location record where the PIDF-LO for + the Location Target resides. The LocationURI is always + represented in ASCII. 2.2 Overall Format of LocationURI Option in IPv6 The LocationURI Option format for IPv6 is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LocationURI... . - . (see Section 2.3 for details) | + . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. IPv6 fields of this LocationURI Option option-code: The code for this DHCPv6 option (IANA assigned). option-len: The length of this option, counted in bytes - not - counting the Code and Length bytes. This is a variable - length Option, therefore the length value will change - based on the length of the URI within the Option. + counting the option-code and option-len bytes. This is + a variable length Option, therefore the length value + will change based on the length of the URI within the + Option. - LocationURI: see below (Section 2.3 for details). + LocationURI: see Section 2.1 -2.3 LocationURI Format for both IPv4 and IPv6 +2.3 Overall Format of Valid-For Option in IPv4 - The LocationURI, in both DHCPv4 and DHCPv6, have the following - format: + The Valid-For Option format for IPv4 is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LuriType | LuriLength | LuriValue ... + | Code XXX | Valid-For ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ..... Valid-For | + +-+-+-+-+-+-+-+-+ - Figure 3. LocationURI TLV Format for both IPv4 and IPv6 + Figure 1. IPv4 Fields for this Valid-For Option - LuriType: A one-byte identifier of the data location value. + Code XXX: The code for this DHCPv4 option (IANA assigned). - LuriLength: The length of the LuriValue, not including the - LuriLength field itself, up to a maximum of 255 - units. The unit of measurement is defined by the - LuriType field definition. The LuriLength itself is - always a one-byte unsigned integer. + Valid-For: Valid-For - The time, in seconds, the LocationURI - + received in the same DHCP message - is to be + considered valid for dereferencing. The Valid-For is + always represented as a four-byte unsigned integer. - LuriValue: The LocationURI value, as described in detail below. +2.4 Overall Format of Valid-For Option in IPv6 - The LuriTypes this document defines for a point are: + The Valid-For Option format for IPv6 is as follows: - LuriType=1 Location URI - This field, in bytes, is the URI - pointing at the location record where the PIDF-LO for - the Location Target resides. The LuriValue of - LuriType=1 is always represented in UTF-8. + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | option-code | Valid-For ..... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ..... Valid-For (Cont'd) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - LuriType=2 Valid-For - The time, in seconds, this URI is to be - considered Valid for dereferencing. The timer - associated with this LuriType starts upon receipt of - this Option by the client. The LuriValue of LuriType=2 - is always represented as a four-byte unsigned integer. + Figure 2. IPv6 fields of this Valid-For Option - The Valid-For (LuriType=2) indicates how long, in seconds, the - client is to consider this location URI (LuriType=1) valid. - Applications MUST NOT make use of a location URI after it becomes - invalid (i.e., after the Valid-For timer expires). + option-code: The code for this DHCPv6 option (IANA assigned). + + Valid-For: see Section 2.3 + +2.5 Rules for both LocationURI and Valid-For Options + + The LocationURI and Valid-For Options have the following + rules: + + o Implementation of the Location URI Option is mandatory on the DHCP + server and client, per this specification. + + o Implementation of the Valid-For Option is OPTIONAL on the DHCP + server and client, per this specification. + + o The Location URI Option MUST be sent from a server, and received + by a client with or without an accompanying Valid-For Option. + + The Valid-For Option offers no meaningful information to a client + without an accompanying Location URI Option, and might be + misunderstood or misapplied, therefore + + o The Valid-For Option MUST NOT be sent from a server, and received + by a client, without an accompanying Location URI Option. + + o A client receiving a Valid-For Option without a Location URI + Option MUST ignore the Valid-For Option. + + o The Valid-For Option MUST only be considered in relation to the + Location URI Option. It has no other purpose in DHCP then in + relation to the Location URI (i.e., there is no other Option in + DHCP to which it has meaning). + + o The Valid-For Option MUST NOT cause any error in handling the + Location URI, i.e., if not understood, it MUST be ignored. + + o Servers MUST assume that clients will overwrite any existing, + previously sent values of Location URI Option and/or Valid-For + Option. + + o Clients MUST overwrite any existing, previously sent values of + Location URI Option and/or Valid-For Option when receiving the + next instance of either Option. The choice of the Valid-For value is a policy decision for the operator of the DHCP server. Like location URIs themselves, it can be statically configured on the DHCP server or provisioned dynamically (via an out-of-band exchange with a Location Information Server) as requests for location URIs are received. + o Clients receiving both a Location URI and Valid-For Options start + the Valid-For timer upon receipt of the DHCP message containing + both Options. + + o All Valid-For Options MUST be no longer than the existing DHCP + lease timer. All received Valid-For values MUST be tuned by the + client to the client's existing refresh timer. + + o For any received Valid-For values longer than the existing DHCP + lease time, the client MUST tune to the client's to be no longer + than existing lease timer. + + o For Valid-For values shorter than the client's lease time, the + Location URI Option MUST be deleted (i.e., not accessible to any + client applications) unless both the Location URI and Valid-For + Options are refreshed. + + o Applications MUST NOT make use of a location URI after it becomes + invalid (i.e., after the Valid-For timer expires). + The Valid-For timer is used only at the application layer, as an indication of when the URI can be used to access location. It is independent of the DHCP lease timer, and in no way related to the - DHCP state machine. Clients MUST NOT trigger an automatic DHCP - refresh on expiry of the Valid-For timer; rather, they should follow - normal DHCP mechanics. + DHCP state machine. + + o Clients MUST NOT trigger an automatic DHCP refresh on expiry of + the Valid-For timer; rather, they SHOULD follow normal DHCP + mechanics. Server operators should consider the relation between the Valid-For time and the lease time. Clients typically request a lease refresh when half the lease time is up. If the Valid-For time is less than the typical refresh rate (i.e., half the lease time), then for the remaining interval, clients will run the risk of not having a usable location URI for applications. If the Valid-For time is less than half the typical refresh rate, it is a near certainty clients will not have a usable location URI for the interval between the - Valid-For time and the typical refresh time for applications. - - For example, if a lease is set to 24 hours, the typical refresh - request is set to initiate at the 12 hour mark. If the Valid-For - timer is set to less than 24 hours, but more than 12 hours (in this - example), the client might not be refreshed at the 12 hour mark and - runs the risk of not have a location URI for applications that - request it. If, on the other hand, the Valid-For timer is less than - 12 hours (in this example, which is before a typical client would - ask for a refresh, applications will be without a usable location - URI until the full refresh has been received. - - It should be expected that clients will overwrite any previous - Option values when receiving a new instance of that Option number. - - The Valid-For (LuriType=2) offers no meaningful information without - an accompanying Location URI (LuriType=1), therefore a Valid-For - (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1). - - The Valid-For (LuriType=2) is not mandated for use by this document. - However, its presence MUST NOT cause any error in handling the - location URI (i.e., if not understood, it MUST be ignored). - - This Option format is highly extensible. Additional LuriType types - created MUST be done so through IANA registration with a standards - track RFC. + Valid-For time and the typical refresh time for applications. For + example, if a lease is set to 24 hours, the typical refresh request + is set to initiate at the 12 hour mark. If the Valid-For timer is + set to less than 24 hours, but more than 12 hours (in this example), + the client might not be refreshed at the 12 hour mark and runs the + risk of not have a location URI for applications that request it. + If, on the other hand, the Valid-For timer is less than 12 hours (in + this example, which is before a typical client would ask for a + refresh, applications will be without a usable location URI until + the full refresh has been received. 3. DHCP Option Operation The [RFC3046] RAIO can be utilized to provide the appropriate indication to the DHCP Server where this DISCOVER or REQUEST message came from, in order to supply the correct response. Caution SHOULD always be used involving the creation of large Options, meaning that this Option MAY need to be in its own INFORM, OPTION or ACK message. @@ -336,35 +392,35 @@ non-concatenated, overwrite the previous value. Location URIs MUST NOT reveal identity information of the user of the device, since DHCP is a cleartext delivery protocol. For example, creating a location URI such as sips:34LKJH534663J54@example.com is better than a location URI such as - sips:aliceisat123mainstalantageorgiaus@example.com + sips:aliceisat123mainstatlantageorgiaus@example.com The username portion of the first example URI provides no direct identity information (in which 34LKJH534663J54 is considered to be a random number in this example). In the element of a PIDF-LO document, there is an - 'entity' attribute that identities what entity *this* document - (including the associated location) refers to. It is up to the - PIDF-LO generator, either Location Server or an application in the - endpoint, to insert the identity in the 'entity' attribute. This - can be seen in [RFC4119]. The considerations for populating the - entity attribute value in a PIDF-LO document are independent from - the considerations for avoiding exposing identification information - in the username part of a location URI. + 'entity' attribute that identifies what entity *this* presence + document (including the associated location) refers to. It is up to + the PIDF-LO generator, either Location Server or an application in + the endpoint, to insert the identity in the 'entity' attribute. + This can be seen in [RFC4119]. The considerations for populating + the entity attribute value in a PIDF-LO document are independent + from the considerations for avoiding exposing identification + information in the username part of a location URI. This Option is used only for communications between a DHCP client and a DHCP server. It can be solicited (requested) by the client, or it can be pushed by the server without a request for it. DHCP Options not understood MUST be ignored [RFC2131]. A DHCP server supporting this Option might or might not have the location of a client. If a server does not have a client's location, but needs to provide this Location URI Option to a client (for whatever reason), an LS is contacted. This server-to-LS transaction is not DHCP, therefore it is out of scope of this document. Note that this @@ -389,55 +445,54 @@ 3.1 Architectural Assumptions The following assumptions have been made for use of this LocationURI Option for a client to learn its location URI (in no particular order): o Any user control (what [RFC3693] calls a 'Ruleholder') for access to the dereferencing step is assumed to be out of scope of this document. An example authorization policy is in [ID-GEO-POL]. - o The authorization vs. possession security model can be found in - [RFC5808], describing what is expected in each model of - operation. It should be assumed that a location URI attained - using DHCP will operate under an possession model by default. - - An authorization model can be instituted as a matter of local - policy. An authorization model means possessing the location URI - does not give that entity the right to view the PIDF-LO of the - target whose location is indicated in a presence document. The - dereference transaction will be challenged by the Location Server - only in an authorization model. The nature of this challenge is - out of scope of this document. + o The authorization security model vs. possession security model + discussion can be found in [RFC5606], describing what is expected + in each model of operation. It should be assumed that a location + URI attained using DHCP will operate under an possession model by + default. An authorization model can be instituted as a matter of + local policy. An authorization model means possessing the + location URI does not give that entity the right to view the + PIDF-LO of the target whose location is indicated in a presence + document. The dereference transaction will be challenged by the + Location Server only in an authorization model. The nature of + this challenge is out of scope of this document. o This document does not prevent some environments from operating in an authorization model, for example - in less tightly controlled networks. The costs associated with authorization vs. possession models are discussed in Section 3.3.2 of [RFC5606]. 3.2 Harmful URIs and URLs There are, in fact, some types of URIs that are not good to receive, due to security concerns. For example, any URLs that can have scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web pages that have scripts. Therefore, o URIs received via this Option MUST NOT be automatically sent to a general-browser to connect to a web page, because they could have harmful scripts. o This Option MUST NOT contain "data:" URLs, because they could contain harmful scripts. - Instead of listing all the types of URIs and URLs that can be - misused or potentially have harmful effects, Section 3.3 IANA - registers acceptable location URI schemes (or types). + o Section 3.3 IANA registers acceptable location URI schemes (or + types) for use by this specification. Clients MUST reject URI + schemes not currently registered in IANA. 3.3 Valid Location URI Schemes or Types This section specifies which URI types are acceptable as a location URI scheme (or type) for this DHCP Option: 1. sip: 2. sips: 3. pres: 4. http: @@ -446,106 +501,97 @@ URIs using the "pres" scheme are dereferenced using the presence event package for SIP [RFC3856], so they will reference a PIDF-LO document when location is available. Responses to requests for URIs with other schemes ("sip", "sips", "http", and "https") MUST have MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS URIs MAY refer to information with MIME type 'application/held+xml', in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can indicate which MIME types they support using the "Accept" header field in SIP [RFC3261] or HTTP [RFC2616]. - See RFC 3922 [RFC3922] for using the pres: URI with XMPP. + See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP. It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442 [RFC6442] as guidance regarding which Location URI schemes to provide in DHCP. That document discusses what a receiving entity does when receiving a URI scheme that is not understood. Awareness to the two URI types there is important for conveying location, if SIP is used to convey a Location URI provided by DHCP. 4. IANA Considerations -4.1 The IPv4 Option number for this Option - - This document IANA registers this IPv4 Option number XXX (to be - assigned by IANA once this document becomes an RFC). +4.1 The IPv4 Option number for the Location URI Option -4.2 The IPv6 Option-Code for this Option + This document IANA registers the Location URI IPv4 Option number XXX + (to be assigned by IANA once this document becomes an RFC). - This document IANA registers this IPv6 Option-Code XXX (to be - assigned by IANA once this document becomes an RFC). +4.2 The IPv6 Option-Code for the Location URI Option -4.3 IANA Considerations for LuriTypes + This document IANA registers the Location URI IPv6 Option-Code XXX + (to be assigned by IANA once this document becomes an RFC). - IANA is requested to create a new registry for acceptable location - types defined in Section 3.2 of this document, arranged similar to - this: +4.3 The IPv4 Option number for the Valid-For Option - +------------+----------------------------------------+-----------+ - | LuriType | Name | Reference | - +------------+----------------------------------------+-----------+ - | 1 | Location URI | RFC XXXX* | - | 2 | Valid-For | RFC XXXX* | - +------------+----------------------------------------+-----------+ + This document IANA registers the Valid-For IPv4 Option number XXX + (to be assigned by IANA once this document becomes an RFC). - * RFC XXXX is to be replaced with this document's RFC-Editor RFC - number. +4.4 The IPv6 Option-Code for the Valid-For Option - Additions to this registry require a standards track RFC. + This document IANA registers the Valid-For IPv6 Option-Code XXX (to + be assigned by IANA once this document becomes an RFC). 5. Security Considerations Where critical decisions might be based on the value of this location URI option, DHCP authentication in [RFC3118] SHOULD be used to protect the integrity of the DHCP options. - A real concern with RFC 3118 it is that not widely deployed because - it requires pre-shared keys to successfully work (i.e., in the - client and in the server). Most implementations do not + A real concern with RFC 3118 is that it is not widely deployed + because it requires pre-shared keys to successfully work (i.e., in + the client and in the server). Most implementations do not accommodate this. DHCP, initially, is a broadcast request (a client looking for a server), and a unicast response (answer from a server) type of protocol. It does not provide security at the network layer. Instead, it relies on lower-layer security mechanisms. - Once a client has a URI, it needs information on how the location - server will control access to dereference requests. A client might - treat a tightly access-controlled URI differently from one that can - be dereferenced by anyone on the Internet (i.e., one following the - "possession model"). With the LuriTypes defined in this document, - the DHCP option for delivering location URIs can only tell the user - how long the URI will be valid. Since the client does not know what - policy will be applied during this validity interval, clients MUST - handle location URIs as if they could be dereferenced by anybody - until they expire. For example, such open location URIs should only - be transmitted in encrypted channels. Nonetheless, location servers - SHOULD apply appropriate access control policies, for example by - limiting the number of queries that any given client can make, or - limiting access to users within an enterprise. + Once a client has a Location URI, it needs information on how the + location server will control access to dereference requests. A + client might treat a tightly access-controlled URI differently from + one that can be dereferenced by anyone on the Internet (i.e., one + following the "possession model"). Since the client does not know + what policy will be applied during this validity interval, clients + MUST handle location URIs as if they could be dereferenced by + anybody until they expire. For example, such open location URIs + should only be transmitted in encrypted channels. Nonetheless, + location servers SHOULD apply appropriate access control policies, + for example by limiting the number of queries that any given client + can make, or limiting access to users within an enterprise. Extensions to this option, such as [ID-POLICY-URI] can provide mechanisms for accessing and provisioning policy. Giving users access to policy information will allow them to make more informed decisions about how to use their location URIs. Allowing users to provide policy information to the LS will enable them to tailor access control policies to their needs (within the bounds of policy that the LS will accept). As to the concerns about the location URI itself, as stated in the document (see Section 3), it MUST NOT have any user identifying information in the URI user-part/string itself. The location URI also needs to be hard to guess that it belongs to a specific user. - When implementing a DHCP server that will serve clients across an - uncontrolled network, one should consider the potential security - risks therein. + In some cases a DHCP server may be implemented across an + uncontrolled network. In those cases, it would be appropriate for a + network administrator to perform a threat analysis (see RFC 3552) + and take precautions as needed. 6. Acknowledgements Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Robert Sparks for their useful comments. And to Lisa Dusseault for her concerns about the types of URIs that can cause harm. To Richard Barnes for inspiring a more robust Security Considerations section, and for offering the text to incorporate HTTP URIs. To Hannes Tschofenig and Ted Hardie for riding me to comply with their concerns, including a good scrubbing of the nearly final doc. @@ -606,25 +652,25 @@ (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", August 2009 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010 - [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. - Thomson, M. Dawson, "A Location Dereferencing Protocol Using - HELD", "work in progress", October 2011 + [RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, + M. Dawson, "A Location Dereferencing Protocol Using HELD", + "work in progress", October 2011 - [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. + [RFC6772] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", "work in progress", October 2011 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location Configuration Extensions for Policy Management", "work in progress", November 2011 Authors' Address