draft-ietf-drip-arch-03.txt   draft-ietf-drip-arch-04.txt 
DRIP S. Card, Ed. DRIP S. Card, Ed.
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 14 January 2021 R. Moskowitz Expires: 1 May 2021 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao S. Zhao
Tencent Tencent
A. Gurtov A. Gurtov
Linköping University Linköping University
13 July 2020 28 October 2020
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-03 draft-ietf-drip-arch-04
Abstract Abstract
This document defines an architecture for protocols and services to This document defines an architecture for protocols and services to
support Unmanned Aircraft System Remote Identification and tracking support Unmanned Aircraft System Remote Identification and tracking
(UAS RID), plus RID-related communications, including required (UAS RID), plus RID-related communications, including required
architectural building blocks and their interfaces. architectural building blocks and their interfaces.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 14 January 2021. This Internet-Draft will expire on 1 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 5 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 6
3. Entities and their Interfaces . . . . . . . . . . . . . . . . 6 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 6
3.1. Private Information Registry . . . . . . . . . . . . . . 6 3.1. Private Information Registry . . . . . . . . . . . . . . 6
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 6 3.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7
3.2. Public Information Registry . . . . . . . . . . . . . . . 7 3.2. Public Information Registry . . . . . . . . . . . . . . . 7
3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Background . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 7 3.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 8
3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 7 3.3. CS-RID concept . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8 3.3.1. Proposed optional CS-RID SDSP . . . . . . . . . . . . 8
3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 8 3.3.2. Proposed optional CS-RID Finder . . . . . . . . . . . 9
4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 9 4.2. Proposed Approach . . . . . . . . . . . . . . . . . . . . 10
5. DRIP Transactions enabling Trustworthy UAS RID . . . . . . . 10 5. DRIP Transactions enabling Trustworthy UAS RID . . . . . . . 10
6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 10 6. Privacy for Broadcast PII . . . . . . . . . . . . . . . . . . 11
7. Architectural implications of EASA requirements . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic
Management (UTM) . . . . . . . . . . . . . . . . . . . . 15 Management (UTM) . . . . . . . . . . . . . . . . . . . . 16
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 16 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 16
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 16 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 17
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 17 A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 17
A.4. Overview UAS Remote ID (RID) and RID Standardization . . 17 A.4. Overview UAS Remote ID (RID) and RID Standardization . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Architectural implications of EASA requirements . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document describes a natural Internet based architecture for This document describes a natural Internet based architecture for
Unmanned Aircraft System Remote Identification and tracking (UAS Unmanned Aircraft System Remote Identification and tracking (UAS
RID), conforming to proposed regulations and external technical RID), conforming to proposed regulations and external technical
standards, satisfying the requirements listed in the companion standards, satisfying the requirements listed in the companion
requirements document [drip-requirements]. The requirements document requirements document [drip-requirements]. The requirements document
also provides an extended introduction to the problem space, use also provides an extended introduction to the problem space, use
cases, etc. Only a brief summary of that introduction will be cases, etc. Only a brief summary of that introduction will be
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Via the direct Radio Frequency (RF) link between the UA and GCS: Via the direct Radio Frequency (RF) link between the UA and GCS:
Command and Control (C2) flows from the GCS to the UA; for all but Command and Control (C2) flows from the GCS to the UA; for all but
the simplest hobby aircraft, position and status flow from the UA to the simplest hobby aircraft, position and status flow from the UA to
the GCS. Via the Internet, through three distinct segments, Network the GCS. Via the Internet, through three distinct segments, Network
RID information flows from the UAS (comprising the UA and its GCS) to RID information flows from the UAS (comprising the UA and its GCS) to
the Observer. the Observer.
Other Standards Development Organizations (SDOs, e.g., 3GPP, Other Standards Development Organizations (SDOs, e.g., 3GPP,
Appendix A.4) may define their own communication methods for both Appendix A.4) may define their own communication methods for both
Network and Broadcast RID. The CAAs expect any additional methods to Network and Broadcast RID. The CAAs expect any additional methods to
maintain consistency of the RID messages. maintain consistency of the RID messages. Encapsulation of Broadcast
RID messages in IP packets is infeasible over data links that support
only very small transmission frames, such as the [F3411-19] specified
Bluetooth 4 one-way advertisements, which cannot fit IP much less
transport layer overhead (even with header compression); but emerging
data links such as [I-D.maeurer-raw-ldacs] should not suffer such
severe limitations.
For sharing location information, manned aviation uses a technology
known as Automatic Dependent Surveillance Broadcast (ADS-B), which is
a ground and satellite based system designed in the early 2000s.
Broadcast RID is conceptually similar to ADS-B. However, for
numerous technical and regulatory reasons, ADS-B itself is not
suitable for low-flying small UA. Technical reasons include: needing
RF-LOS to large, expensive (hence scarce) ground stations; needing
both a satellite receiver and 1090 MHz transceiver onboard CSWaP
constrained UA; the limited bandwidth of both uplink and downlink,
which are adequate for the current manned aviation traffic volume,
but would likely be saturated by large numbers of UAS, endangering
manned aviation; etc. Understanding these technical shortcomings,
regulators world-wide have ruled out use of ADS-B for the small UAS
for which UAS RID and DRIP are intended.
DRIP will enable leveraging existing Internet resources (standard DRIP will enable leveraging existing Internet resources (standard
protocols, services, infrastructure and business models) to meet UAS protocols, services, infrastructure and business models) to meet UAS
RID and closely related needs. DRIP will specify how to apply IETF RID and closely related needs. DRIP will specify how to apply IETF
standards, complementing [F3411-19] and other external standards, to standards, complementing [F3411-19] and other external standards, to
satisfy UAS RID requirements. DRIP will update existing and develop satisfy UAS RID requirements. DRIP will update existing and develop
new protocol standards as needed to accomplish the foregoing. new protocol standards as needed to accomplish the foregoing.
This document will outline the UAS RID architecture into which DRIP This document will outline the UAS RID architecture into which DRIP
must fit, and an architecture for DRIP itself. This includes must fit, and an architecture for DRIP itself. This includes
skipping to change at page 7, line 7 skipping to change at page 7, line 32
A DRIP private information registry MUST support essential Internet A DRIP private information registry MUST support essential Internet
domain name registry operations (e.g. add, delete, update, query) domain name registry operations (e.g. add, delete, update, query)
using interoperable open standard protocols. It SHOULD support the using interoperable open standard protocols. It SHOULD support the
Extensible Provisioning Protocol (EPP) and the Registry Data Access Extensible Provisioning Protocol (EPP) and the Registry Data Access
Protocol (RDAP) with access controls. It MAY use XACML to specify Protocol (RDAP) with access controls. It MAY use XACML to specify
those access controls. It MUST be listed in a DNS: that DNS MAY be those access controls. It MUST be listed in a DNS: that DNS MAY be
private; but absent any compelling reasons for use of private DNS, private; but absent any compelling reasons for use of private DNS,
SHOULD be the definitive public Internet DNS hierarchy. The DRIP SHOULD be the definitive public Internet DNS hierarchy. The DRIP
private information registry in which a given UAS is registered MUST private information registry in which a given UAS is registered MUST
be locatable, starting from the UAS ID, using the methods specified be locatable, starting from the UAS ID, using the methods specified
in [RFC7484]. in [RFC7484]. A DRIP private information registry MAY support
WebFinger as specified in [RFC7033].
3.2. Public Information Registry 3.2. Public Information Registry
3.2.1. Background 3.2.1. Background
The public information required to be made available by UAS RID is The public information required to be made available by UAS RID is
transmitted as cleartext to local observers in Broadcast RID and is transmitted as cleartext to local observers in Broadcast RID and is
served to a client by a Net-RID DP in Network RID. Therefore, while served to a client by a Net-RID DP in Network RID. Therefore, while
IETF can offer e.g. [RFC6280] as one way to implement Network RID, IETF can offer e.g. [RFC6280] as one way to implement Network RID,
the only public information required to support essential DRIP the only public information required to support essential DRIP
functions for UAS RID is that required to look up Internet domain functions for UAS RID is that required to look up Internet domain
hosts, services, etc. hosts, services, etc.
3.2.2. Proposed Approach 3.2.2. Proposed Approach
A DRIP public information registry MUST be a standard DNS server, in A DRIP public information registry MUST be a standard DNS server, in
the definitive public Internet DNS hierarchy. It MUST support NS, the definitive public Internet DNS hierarchy. It MUST support NS,
MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005]) MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per [RFC8005])
types. types. If a DRIP public information registry lists, in a HIP RR, any
HIP RVS servers for a given DRIP UAS ID, those RVS servers MUST
restrict relay services per AAA policy; this may require extensions
to [RFC8004]
3.3. CS-RID concept 3.3. CS-RID concept
ASTM anticipated that regulators would require both Broadcast RID and ASTM anticipated that regulators would require both Broadcast RID and
Network RID for large UAS, but allow RID requirements for small UAS Network RID for large UAS, but allow RID requirements for small UAS
to be satisfied with the operator's choice of either Broadcast RID or to be satisfied with the operator's choice of either Broadcast RID or
Network RID. The EASA initially specified Broadcast RID for UAS of Network RID. The EASA initially specified Broadcast RID for UAS of
essentially all UAS and is now considering Network RID also. The FAA essentially all UAS and is now considering Network RID also. The FAA
NPRM requires both for Standard RID and specifies Broadcast RID only NPRM requires both for Standard RID and specifies Network RID only
for Limited RID. One obvious opportunity is to enhance the for Limited RID. One obvious opportunity is to enhance the
architecture with gateways from Broadcast RID to Network RID. This architecture with gateways from Broadcast RID to Network RID. This
provides the best of both and gives regulators and operators provides the best of both and gives regulators and operators
flexibility. Such gateways could be pre-positioned (e.g. around flexibility. Such gateways could be pre-positioned (e.g. around
airports and other sensitive areas) and/or crowdsourced (as nothing airports and other sensitive areas) and/or crowdsourced (as nothing
more than a smartphone with a suitable app is needed). Gateways can more than a smartphone with a suitable app is needed). As Broadcast
also perform multilateration to provide independent measurements of RID media have limited range, gateways receiving messages claiming
UA position, which is otherwise entirely operator self-reported in locations far from the gateway can alert authorities or a SDSP to the
UAS RID and UTM. CS-RID would be an option, beyond baseline DRIP failed sanity check possibly indicating intent to deceive.
functionality; if implemented, it adds two more entity types. Surveillance SDSPs can use messages with precise date/time/position
stamps from the gateways to multilaterate UA location, independent of
the locations claimed in the messages, which are entirely operator
self-reported in UAS RID and UTM. Further, gateways with additional
sensors (e.g. smartphones with cameras) can provide independent
information on the UA type and size, confirming or refuting those
claims made in the RID messages. CS-RID would be an option, beyond
baseline DRIP functionality; if implemented, it adds two more entity
types.
3.3.1. Proposed optional CS-RID SDSP 3.3.1. Proposed optional CS-RID SDSP
A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net- A CS-RID SDSP MUST appear (i.e. present the same interface) to a Net-
RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as RID SP as a Net-RID DP. A CS-RID SDSP MUST appear to a Net-RID DP as
a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing a Net-RID SP. A CS-RID SDSP MUST NOT present a standard GCS-facing
interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present interface as if it were a Net-RID SP. A CS-RID SDSP MUST NOT present
a standard client-facing interface as if it were a Net-RID DP. A CS- a standard client-facing interface as if it were a Net-RID DP. A CS-
RID SDSP MUST present a TBD interface to a CS-RID Finder; this RID SDSP MUST present a TBD interface to a CS-RID Finder; this
interface SHOULD be based upon but readily distinguishable from that interface SHOULD be based upon but readily distinguishable from that
skipping to change at page 11, line 25 skipping to change at page 12, line 15
PII is protected unless the UAS is informed otherwise. This may come PII is protected unless the UAS is informed otherwise. This may come
from operational instructions to even permit flying in a space/time. from operational instructions to even permit flying in a space/time.
It may be special instructions at the start or during an operation. It may be special instructions at the start or during an operation.
PII protection should not be used if the UAS loses connectivity to PII protection should not be used if the UAS loses connectivity to
the USS. The USS always has the option to abort the operation if PII the USS. The USS always has the option to abort the operation if PII
protection is disallowed. protection is disallowed.
An authorized Observer may instruct a UAS via the USS that conditions An authorized Observer may instruct a UAS via the USS that conditions
have changed mandating no PII protection or land the UA. have changed mandating no PII protection or land the UA.
7. Architectural implications of EASA requirements 7. IANA Considerations
According to EASA, in EU broadcasting drone identification will be
mandatory from July 2020. Following info should be sent in cleartext
over Wifi or Bluetooth. In real time during the whole duration of
the flight, the direct periodic broadcast from the UA using an open
and documented transmission protocol, of the following data, in a way
that they can be received directly by existing mobile devices within
the broadcasting range:
i) the UAS operator registration number;
ii) the unique physical serial number of the UA compliant with
standard ANSI/CTA2063;
iii) the geographical position of the UA and its height above the
surface or take-off point;
iv) the route course measured clockwise from true north and ground
speed of the UA; and
v) the geographical position of the remote pilot or, if not
available, the take-off point;
The architecture proposed in this document partially satisfies EASA
requirements. In particular, i) is included to Operator-ID Message
as optional. ii) cannot be directly supported due to its heavy
privacy implications. A cryptographic identifier that needs to be
resolved is proposed instead. iii) and iv) are included into
Location/Vector Message. v) is included into a System Message
(optional).
8. IANA Considerations
This document does not make any request to IANA. This document does not make any request to IANA.
9. Security Considerations 8. Security Considerations
DRIP is all about safety and security, so content pertaining to such DRIP is all about safety and security, so content pertaining to such
is not limited to this section. The security provided by asymmetric is not limited to this section. The security provided by asymmetric
cryptographic techniques depends upon protection of the private keys. cryptographic techniques depends upon protection of the private keys.
A manufacturer that embeds a private key in an UA may have retained a A manufacturer that embeds a private key in an UA may have retained a
copy. A manufacturer whose UA are configured by a closed source copy. A manufacturer whose UA are configured by a closed source
application on the GCS which communicates over the Internet with the application on the GCS which communicates over the Internet with the
factory may be sending a copy of a UA or GCS self-generated key back factory may be sending a copy of a UA or GCS self-generated key back
to the factory. Compromise of a registry private key could do to the factory. Keys may be extracted from a GCS or UA; the RID
widespread harm. Key revocation procedures are as yet to be sender of a small harmless UA (or the entire UA) could be carried by
determined. These risks are in addition to those involving Operator a larger dangerous UA as a "false flag." Compromise of a registry
key management practices. private key could do widespread harm. Key revocation procedures are
as yet to be determined. These risks are in addition to those
involving Operator key management practices.
10. References 9. References
10.1. Normative References 9.1. Normative References
[drip-requirements] [drip-requirements]
Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov,
"Drone Remote Identification Protocol (DRIP) "Drone Remote Identification Protocol (DRIP)
Requirements", Work in Progress, Internet-Draft, draft- Requirements", Work in Progress, Internet-Draft, draft-
ietf-drip-reqs-01, 25 May 2020, ietf-drip-reqs-05, 16 October 2020,
<https://tools.ietf.org/html/draft-ietf-drip-reqs-01>. <https://tools.ietf.org/html/draft-ietf-drip-reqs-05>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[ATIS-I-0000074] [ATIS-I-0000074]
ATIS, "Report on UAS in 3GPP", ATIS, "Report on UAS in 3GPP",
<https://access.atis.org/apps/group_public/ <https://access.atis.org/apps/group_public/
download.php/48760/ATIS-I-0000074.pdf>. download.php/48760/ATIS-I-0000074.pdf>.
[crowd-sourced-rid] [crowd-sourced-rid]
Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and Moskowitz, R., Card, S., Wiethuechter, A., Zhao, S., and
H. Birkholz, "Crowd Sourced Remote ID", Work in Progress, H. Birkholz, "Crowd Sourced Remote ID", Work in Progress,
Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04, Internet-Draft, draft-moskowitz-drip-crowd-sourced-rid-04,
skipping to change at page 13, line 29 skipping to change at page 13, line 35
[Delegated] [Delegated]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Delegated Regulation 2019/945 of 12 March 2019 Commission Delegated Regulation 2019/945 of 12 March 2019
on unmanned aircraft systems and on third-country on unmanned aircraft systems and on third-country
operators of unmanned aircraft systems", March 2019. operators of unmanned aircraft systems", March 2019.
[drip-auth] [drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Authentication Formats", Work in Progress, Internet-Draft, Authentication Formats", Work in Progress, Internet-Draft,
draft-wiethuechter-drip-auth-01, 10 July 2020, draft-wiethuechter-drip-auth-04, 21 September 2020,
<https://tools.ietf.org/html/draft-wiethuechter-drip-auth- <https://tools.ietf.org/html/draft-wiethuechter-drip-auth-
01>. 04>.
[drip-identity-claims] [drip-identity-claims]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Identity Claims", Work in Progress, Internet-Draft, draft- Identity Claims", Work in Progress, Internet-Draft, draft-
wiethuechter-drip-identity-claims-00, 23 March 2020, wiethuechter-drip-identity-claims-02, 26 October 2020,
<https://tools.ietf.org/html/draft-wiethuechter-drip- <https://tools.ietf.org/html/draft-wiethuechter-drip-
identity-claims-00>. identity-claims-02>.
[drip-secure-nrid-c2] [drip-secure-nrid-c2]
Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"Secure UAS Network RID and C2 Transport", Work in "Secure UAS Network RID and C2 Transport", Work in
Progress, Internet-Draft, draft-moskowitz-drip-secure- Progress, Internet-Draft, draft-moskowitz-drip-secure-
nrid-c2-00, 6 April 2020, <https://tools.ietf.org/html/ nrid-c2-01, 27 September 2020,
draft-moskowitz-drip-secure-nrid-c2-00>. <https://tools.ietf.org/html/draft-moskowitz-drip-secure-
nrid-c2-01>.
[drip-uas-rid] [drip-uas-rid]
Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"UAS Remote ID", Work in Progress, Internet-Draft, draft- "UAS Remote ID", Work in Progress, Internet-Draft, draft-
moskowitz-drip-uas-rid-02, 28 May 2020, moskowitz-drip-uas-rid-06, 17 August 2020,
<https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid- <https://tools.ietf.org/html/draft-moskowitz-drip-uas-rid-
02>. 06>.
[F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking",
December 2019. December 2019.
[hhit-registries] [hhit-registries]
Moskowitz, R., Card, S., and A. Wiethuechter, Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet- "Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-02, 9 March Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
2020, <https://tools.ietf.org/html/draft-moskowitz-hip- 2020, <https://tools.ietf.org/html/draft-moskowitz-hip-
hhit-registries-02>. hhit-registries-02>.
[hierarchical-hit] [hierarchical-hit]
Moskowitz, R., Card, S., and A. Wiethuechter, Moskowitz, R., Card, S., and A. Wiethuechter,
"Hierarchical HITs for HIPv2", Work in Progress, Internet- "Hierarchical HITs for HIPv2", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May
2020, <https://tools.ietf.org/html/draft-moskowitz-hip- 2020, <https://tools.ietf.org/html/draft-moskowitz-hip-
hierarchical-hit-05>. hierarchical-hit-05>.
[I-D.maeurer-raw-ldacs]
Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital
Aeronautical Communications System (LDACS)", Work in
Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2
October 2020,
<https://tools.ietf.org/html/draft-maeurer-raw-ldacs-06>.
[Implementing] [Implementing]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Implementing Regulation 2019/947 of 24 May 2019 Commission Implementing Regulation 2019/947 of 24 May 2019
on the rules and procedures for the operation of unmanned on the rules and procedures for the operation of unmanned
aircraft", May 2019. aircraft", May 2019.
[LAANC] United States Federal Aviation Administration (FAA), "Low [LAANC] United States Federal Aviation Administration (FAA), "Low
Altitude Authorization and Notification Capability", Altitude Authorization and Notification Capability",
<https://www.faa.gov/uas/programs_partnerships/ <https://www.faa.gov/uas/programs_partnerships/
data_exchange/>. data_exchange/>.
[new-hip-crypto] [new-hip-crypto]
Moskowitz, R., Card, S., and A. Wiethuechter, "New Moskowitz, R., Card, S., and A. Wiethuechter, "New
Cryptographic Algorithms for HIP", Work in Progress, Cryptographic Algorithms for HIP", Work in Progress,
Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 Internet-Draft, draft-moskowitz-hip-new-crypto-05, 26 July
January 2020, <https://tools.ietf.org/html/draft- 2020, <https://tools.ietf.org/html/draft-moskowitz-hip-
moskowitz-hip-new-crypto-04>. new-crypto-05>.
[new-orchid] [new-orchid]
Moskowitz, R., Card, S., and A. Wiethuechter, "Using Moskowitz, R., Card, S., and A. Wiethuechter, "Using
cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, cSHAKE in ORCHIDs", Work in Progress, Internet-Draft,
draft-moskowitz-orchid-cshake-01, 21 May 2020, draft-moskowitz-orchid-cshake-01, 21 May 2020,
<https://tools.ietf.org/html/draft-moskowitz-orchid- <https://tools.ietf.org/html/draft-moskowitz-orchid-
cshake-01>. cshake-01>.
[NPRM] United States Federal Aviation Administration (FAA), [NPRM] United States Federal Aviation Administration (FAA),
"Notice of Proposed Rule Making on Remote Identification "Notice of Proposed Rule Making on Remote Identification
skipping to change at page 15, line 16 skipping to change at page 15, line 27
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011,
<https://www.rfc-editor.org/info/rfc6280>. <https://www.rfc-editor.org/info/rfc6280>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>. <https://www.rfc-editor.org/info/rfc7401>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <https://www.rfc-editor.org/info/rfc7484>. 2015, <https://www.rfc-editor.org/info/rfc7484>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>. October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[TS-22.825] [TS-22.825]
3GPP, "UAS RID requirement study", 3GPP, "UAS RID requirement study",
<https://portal.3gpp.org/desktopmodules/Specifications/ <https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3527>. SpecificationDetails.aspx?specificationId=3527>.
[TS-36.777] [TS-36.777]
skipping to change at page 18, line 5 skipping to change at page 18, line 29
release 16, it completed the UAS RID requirement study in [TS-22.825] release 16, it completed the UAS RID requirement study in [TS-22.825]
and proposed use cases in the mobile network and the services that and proposed use cases in the mobile network and the services that
can be offered based on RID and ongoing release 17 specification can be offered based on RID and ongoing release 17 specification
works on enhanced UAS service requirement and provides the protocol works on enhanced UAS service requirement and provides the protocol
and application architecture support which is applicable for both 4G and application architecture support which is applicable for both 4G
and 5G network. ATIS's recent report [ATIS-I-0000074] proposes and 5G network. ATIS's recent report [ATIS-I-0000074] proposes
architecture approaches for the 3GPP network to support UAS and one architecture approaches for the 3GPP network to support UAS and one
of which is put RID in higher 3GPP protocol stack such as using ASTM of which is put RID in higher 3GPP protocol stack such as using ASTM
remote ID [F3411-19]. remote ID [F3411-19].
Appendix B. Architectural implications of EASA requirements
According to EASA, in EU broadcasting drone identification will be
mandatory from July 2020. Following info should be sent in cleartext
over Wifi or Bluetooth. In real time during the whole duration of
the flight, the direct periodic broadcast from the UA using an open
and documented transmission protocol, of the following data, in a way
that they can be received directly by existing mobile devices within
the broadcasting range:
i) the UAS operator registration number;
ii) the unique physical serial number of the UA compliant with
standard ANSI/CTA2063;
iii) the geographical position of the UA and its height above the
surface or take-off point;
iv) the route course measured clockwise from true north and ground
speed of the UA; and
v) the geographical position of the remote pilot or, if not
available, the take-off point;
The architecture proposed in this document partially satisfies EASA
requirements. In particular, i) is included to Operator-ID Message
as optional. ii) cannot be directly supported due to its heavy
privacy implications. A cryptographic identifier that needs to be
resolved is proposed instead. iii) and iv) are included into
Location/Vector Message. v) is included into a System Message
(optional).
Acknowledgments Acknowledgments
The work of the FAA's UAS Identification and Tracking (UAS ID) The work of the FAA's UAS Identification and Tracking (UAS ID)
Aviation Rulemaking Committee (ARC) is the foundation of later ASTM Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in
balancing the interests of diverse stakeholders is essential to the balancing the interests of diverse stakeholders is essential to the
necessary rapid and widespread deployment of UAS RID. IETF necessary rapid and widespread deployment of UAS RID. IETF
volunteers who have contributed to this draft include Amelia volunteers who have contributed to this draft include Amelia
Andersdotter and Mohamed Boucadair. Andersdotter and Mohamed Boucadair.
 End of changes. 36 change blocks. 
89 lines changed or deleted 139 lines changed or added

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