LPWAN Overview
draft-ietf-lpwan-overview-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8376.
|
|
|---|---|---|---|
| Author | Stephen Farrell | ||
| Last updated | 2017-06-13 | ||
| Replaces | draft-farrell-lpwan-overview | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
IOTDIR Early review
(of
-08)
by Samita Chakrabarti
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8376 (Informational) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lpwan-overview-04
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6753 Commscope
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Schulzrinne
Columbia University
M. Thomson
Microsoft
October 2012
A Location Dereference Protocol Using
HTTP-Enabled Location Delivery (HELD)
Abstract
This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereference protocol
to resolve a reference to a Presence Information Data Format Location
Object (PIDF-LO). This document assumes that a Location Recipient
possesses a URI that can be used in conjunction with the HTTP-Enabled
Location Delivery (HELD) protocol to request the location of the
Target.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6753.
Winterbottom, et al. Standards Track [Page 1]
RFC 6753 HELD Dereferencing October 2012
Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix B. Compliance to Location Reference Requirements . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 21
B.2. Requirements for a Location Dereference Protocol . . . . . 23
Winterbottom, et al. Standards Track [Page 2]
RFC 6753 HELD Dereferencing October 2012
1. Introduction
A location URI [RFC5808] identifies a resource that contains the
location of an entity. This document specifies how a holder of an
"http:" or "https:" location URI uses that URI to retrieve location
information using a subset of HELD functionality or an HTTP GET
request.
A location URI can be acquired using a location configuration
protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or
the Dynamic Host Configuration Protocol (DHCP) location URI option
[DHCP-URI-OPT].
A Location Recipient that dereferences a location URI acquires
location information in the form of a Presence Information Data
Format - Location Object (PIDF-LO) document [RFC4119]. HELD
parameters allow for specifying the type of location information,
though some constraints are placed on allowable parameters.
Location URIs compatible with HELD dereferencing use the "https:" or
"http:" scheme. HELD can be used by Location Recipients that are
aware of the fact that the URI is a location URI. Mandatory support
for an HTTP GET request ensures that the URI can be used even if it
is not recognized as a location URI.
2. Terminology
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].
This document uses key terminology from several sources:
o The terms for the GEOPRIV reference model defined are in
[RFC6280].
o The term "Location Information Server (LIS)", from [RFC5687], is a
node in the access network that provides location information to
an endpoint. A LIS provides location URIs.
o The term "Location Server (LS)", from [RFC6280], is used to
identify the role that responds to a location dereference request.
A Location Server might be the same entity as the LIS, but the
model in [RFC5808] allows for the existence of separate -- but
related -- entities.
o The term "location URI" is coined in [RFC5808].
Winterbottom, et al. Standards Track [Page 3]
RFC 6753 HELD Dereferencing October 2012
3. HELD Dereference Protocol
This section describes how HELD can be used to dereference a location
URI. This process can be applied when a Location Recipient is in
possession of a location URI with an "https:" or "http:" URI scheme.
This document does not describe a specific authentication mechanism.
This means that authorization policies are unable to specifically
identify authorized Location Recipients.
A Location Recipient that wishes to dereference an "https:" or
"http:" URI performs a HELD request on HTTP to the identified
resource.
Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information, and the Location
Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as
described in [RFC2818].
The scheme of a location URI determines whether or not TLS is used on
a given dereference transaction. Location Servers MUST be configured
to issue only HTTPS URIs and respond to only to HTTPS dereference
requests, unless confidentiality and integrity protection are
provided by some other mechanism. For example, the server might only
accept requests from clients within a trusted network or via an
IPsec-protected channel. When TLS is used, the TLS ciphersuite
TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be
authenticated [RFC6125] to ensure that the correct server is
contacted.
A Location Server MAY reject a request and ask that a Location
Recipient provide authentication credentials if authorization is
dependent on the Location Recipient identity. Future specifications
could define an authentication mechanism and a means by which
Location Recipients are identified in authorization policies. This
document does not provide definitions for either item.
3.1. HELD Usage Profile
Use of HELD as a location dereference protocol is largely the same as
its use as a location configuration protocol. Aside from the
restrictions noted in this document, HELD semantics do not differ
from those established in [RFC5985].
Winterbottom, et al. Standards Track [Page 4]
RFC 6753 HELD Dereferencing October 2012
The HELD "locationRequest" is the only request permitted by this
specification. Similarly, request parameters other than the
following MUST NOT be accepted by the LS: "responseTime" and
"locationType" (including the associated "exact" attribute).
Parameters and requests that do not have known behavior for
dereference requests MUST NOT be used. The LS MUST ignore any
parameters that it does not understand unless it knows the parameters
to be invalid. If parameters are understood by the LS and known to
be invalid, the LS MAY generate a HELD error response. For instance,
those defined in [RFC6155] are always invalid and can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute.
3.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents; therefore,
unless context identifies an "https:" URI as a HELD URI, such a user
agent might simply send an HTTP GET. Rather than providing an HTTP
405 (Method Not Allowed) response indicating that POST is the only
permitted method, a LIS MUST provide a HELD location response if it
receives an HTTP GET request.
An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>
Figure 1: GET Request Equivalent Location Request
HTTP GET requests MUST be safe and idempotent [RFC2616] -- that is,
there are no side effects of making the request, and a repeated
request has no more effect than a single request. Repeating a HELD
request might result in a different location, but only as a result of
a change in the state of the resource: the location of the Target.
Only the creation of a location URI as a result of receiving a
request causes a HELD request to have side effects. A request to a
location URI can be both safe and idempotent, since a location URI
cannot be produced in response to a request to a location URI. A
Winterbottom, et al. Standards Track [Page 5]
Internet-Draft Low Power Wide Area Networking Overview June 2017
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
Farrell Expires December 15, 2017 [Page 36]
Internet-Draft Low Power Wide Area Networking Overview June 2017
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
[I-D.farrell-lpwan-lora-overview]
Farrell, S. and A. Yegin, "LoRaWAN Overview", draft-
farrell-lpwan-lora-overview-01 (work in progress), October
2016.
[I-D.minaburo-lpwan-gap-analysis]
Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and
J. Crowcroft, "LPWAN Survey and GAP Analysis", draft-
minaburo-lpwan-gap-analysis-02 (work in progress), October
2016.
[I-D.zuniga-lpwan-sigfox-system-description]
Zuniga, J. and B. PONSARD, "SIGFOX System Description",
draft-zuniga-lpwan-sigfox-system-description-02 (work in
progress), March 2017.
[I-D.ratilainen-lpwan-nb-iot]
Ratilainen, A., "NB-IoT characteristics", draft-
ratilainen-lpwan-nb-iot-00 (work in progress), July 2016.
[I-D.garcia-dime-diameter-lorawan]
Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
"LoRaWAN Authentication in Diameter", draft-garcia-dime-
diameter-lorawan-00 (work in progress), May 2016.
[I-D.garcia-radext-radius-lorawan]
Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov,
"LoRaWAN Authentication in RADIUS", draft-garcia-radext-
radius-lorawan-03 (work in progress), May 2017.
[TGPP36300]
3GPP, "TS 36.300 v13.4.0 Evolved Universal Terrestrial
Radio Access (E-UTRA) and Evolved Universal Terrestrial
Radio Access Network (E-UTRAN); Overall description; Stage
2", 2016,
<http://www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>.
Farrell Expires December 15, 2017 [Page 37]
Internet-Draft Low Power Wide Area Networking Overview June 2017
[TGPP36321]
3GPP, "TS 36.321 v13.2.0 Evolved Universal Terrestrial
Radio Access (E-UTRA); Medium Access Control (MAC)
protocol specification", 2016.
[TGPP36322]
3GPP, "TS 36.322 v13.2.0 Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio Link Control (RLC) protocol
specification", 2016.
[TGPP36323]
3GPP, "TS 36.323 v13.2.0 Evolved Universal Terrestrial
Radio Access (E-UTRA); Packet Data Convergence Protocol
(PDCP) specification (Not yet available)", 2016.
[TGPP36331]
3GPP, "TS 36.331 v13.2.0 Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio Resource Control (RRC);
Protocol specification", 2016.
[TGPP36201]
3GPP, "TS 36.201 v13.2.0 - Evolved Universal Terrestrial
Radio Access (E-UTRA); LTE physical layer; General
description", 2016.
[TGPP23720]
3GPP, "TR 23.720 v13.0.0 - Study on architecture
enhancements for Cellular Internet of Things", 2016.
[TGPP33203]
3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
for IP-based services", 2016.
[fcc_ref] "FCC CFR 47 Part 15.247 Telecommunication Radio Frequency
Devices - Operation within the bands 902-928 MHz,
2400-2483.5 MHz, and 5725-5850 MHz.", June 2016.
[etsi_ref]
"ETSI EN 300-220 (Parts 1 and 2): Electromagnetic
compatibility and Radio spectrum Matters (ERM); Short
Range Devices (SRD); Radio equipment to be used in the 25
MHz to 1 000 MHz frequency range with power levels ranging
up to 500 mW", May 2016.
[arib_ref]
"ARIB STD-T108 (Version 1.0): 920MHz-Band Telemeter,
Telecontrol and data transmission radio equipment.",
February 2012.
Farrell Expires December 15, 2017 [Page 38]
Internet-Draft Low Power Wide Area Networking Overview June 2017
[LoRaSpec]
LoRa Alliance, "LoRaWAN Specification Version V1.0.2",
July 2016, <http://portal.lora-
alliance.org/DesktopModules/Inventures_Document/
FileDownload.aspx?ContentID=1398>.
[LoRaSpec1.0]
LoRa Alliance, "LoRaWAN Specification Version V1.0", Jan
2015, <https://www.lora-alliance.org/portals/0/specs/
LoRaWAN%20Specification%201R0.pdf>.
[ANSI-4957-000]
ANSI, TIA-4957.000, "Architecture Overview for the Smart
Utility Network", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26rid=TIA%26item_s_key=00606368>.
[ANSI-4957-210]
ANSI, TIA-4957.210, "Multi-Hop Delivery Specification of a
Data Link Sub-Layer", May 2013, <https://global.ihs.com/
doc_detail.cfm?%26csf=TIA%26item_s_key=00601800>.
[wisun-pressie1]
Phil Beecher, Chair, Wi-SUN Alliance, "Wi-SUN Alliance
Overview", March 2017, <http://indiasmartgrid.org/event201
7/10-03-2017/4.%20Roundtable%20on%20Communication%20and%20
Cyber%20Security/1.%20Phil%20Beecher.pdf>.
[wisun-pressie2]
Bob Heile, Director of Standards, Wi-SUN Alliance, "IETF97
Wi-SUN Alliance Field Area Network (FAN) Overview",
November 2016,
<https://www.ietf.org/proceedings/97/slides/slides-97-
lpwan-35-wi-sun-presentation-00.pdf>.
[IEEE-802-15-4]
"IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", IEEE Standard 802.15.4, 2015,
<https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
[IEEE-802-15-9]
"IEEE Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016,
<https://standards.ieee.org/findstds/
standard/802.15.9-2016.html>.
Farrell Expires December 15, 2017 [Page 39]
Internet-Draft Low Power Wide Area Networking Overview June 2017
[etsi_unb]
"ETSI TR 103 435 System Reference document (SRdoc); Short
Range Devices (SRD); Technical characteristics for Ultra
Narrow Band (UNB) SRDs operating in the UHF spectrum below
1 GHz", February 2017.
Appendix A. Changes
A.1. From -00 to -01
o WG have stated they want this to be an RFC.
o WG clearly want to keep the RF details.
o Various changes made to remove/resolve a number of editorial notes
from -00 (in some cases as per suggestions from Ana Minaburo)
o Merged PR's: #1...
o Rejected PR's: #2 (change was made to .txt not .xml but was
replicated manually by editor)
o Github repo is at: https://github.com/sftcd/lpwan-ov
A.2. From -01 to -02
o WG seem to agree with editor suggestions in slides 13-24 of the
presentation on this topic given at IETF98 (See:
https://www.ietf.org/proceedings/98/slides/slides-98-lpwan-
aggregated-slides-07.pdf)
o Got new text wrt Wi-SUN via email from Paul Duffy and merged that
in
o Reflected list discussion wrt terminology and "end-device"
o Merged PR's: #3...
A.3. From -02 to -03
o Editorial changes and typo fixes thanks to Fred Baker running
something called Grammerly and sending me it's report.
o Merged PR's: #4, #6, #7...
o Editor did an editing pass on the lot.
Farrell Expires December 15, 2017 [Page 40]
Internet-Draft Low Power Wide Area Networking Overview June 2017
A.4. From -03 to -04
o Picked up a PR that had been wrongly applied that expands UE
o Editorial changes wrt LoRa suggested by Alper
o Editorial changes wrt SIGFOX provided by Juan-Carlos
Author's Address
Stephen Farrell (editor)
Trinity College Dublin
Dublin 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Farrell Expires December 15, 2017 [Page 41]
RFC 6753 HELD Dereferencing October 2012