Subject: [Drip] I-D Action: draft-ietf-drip-arch-05.txt

From: [email-masked]
Date: Tue, 03 Nov 2020 07:03:51 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : Drone Remote Identification Protocol (DRIP) Architecture
        Authors         : Stuart W. Card
                          Adam Wiethuechter
                          Robert Moskowitz
                          Shuai Zhao
                          Andrei Gurtov
	Filename        : draft-ietf-drip-arch-05.txt
	Pages           : 23
	Date            : 2020-11-03

Abstract:
   This document defines an architecture for protocols and services to
   support Unmanned Aircraft System Remote Identification and tracking
   (UAS RID), plus RID-related communications, including required
   architectural building blocks and their interfaces.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-arch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-drip-arch-05
https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Nov 2020 12:36:30 -0500

> 	Filename        : draft-ietf-drip-arch-05.txt

Comments:

    ASTM

       ASTM International, Technical Committee F38 (UAS), Subcommittee
       F38.02 (Aircraft Operations), Work Item WK65041, developed the new
       ASTM [F3411-19] Standard Specification for Remote ID and Tracking.

       ASTM defines one set of RID information and two means, MAC-layer
       broadcast and IP-layer network, of communicating it.  If a UAS
       uses both communication methods, generally the same information
       must provided via both means.  The [F3411-19] is sighted by FAA in

r/sighted/cited/

I don't know how long I looked at that, knowing something was wrong, 
before my wife looked over my shoulder and pointed out the problem...

    3GPP

       3GPP provides UA service in the LTE network since release 15 in
       published technical specification [TS-36.777].  Start from its
       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 can be offered based on RID and ongoing release 17
       specification works on enhanced UAS service requirement and
       provides the protocol and application architecture support which
       is applicable for both 4G and 5G network.  ATIS's recent report

With release 16, it completed the UAS RID requirement study
       [TS-22.825] and proposed use cases in the mobile network and the
       services that can be offered based on RID.  Release 17
       specification works on enhanced UAS service requirements and
       provides the protocol and application architecture support which
       is applicable for both 4G and 5G network.

1.2.1.  Network RID

    Network RID defines a RID data dictionary and data flow: from a UAS
    via unspecified means to a Network Remote ID Service Provider (Net-

[F3411-19] Network RID defines a RID data dictionary...

or

A RID data dictionary and data flow for Network RID is defined in 
[F3411-19].  This flow is from a UAS via...

then a couple lines down:

r/(Net- RID DP)/(Net-RID DP)/

And this sentence is just too run on and on.  So:

    A RID data dictionary and data flow for Network RID is defined in 
[F3411-19].
    This flow is from a UAS via unspecified means (but at least in part 
over the Internet)
    to a Network Remote ID Service Provider (Net-RID SP).  These Net-RID SP
    provide this information to Network Remote ID Display Providers 
(Net-RID DP).
    It is the Net-RID DP that respond to queries from Network Remote ID 
clients
    (expected typically, but not specified exclusively, to be web based) 
specifying
    airspace volumes of interest.  Network RID depends upon 
connectivity, in several
    segments, via the Internet, from the UAS to the Observer.

In Fig 1:  UA to Internet direct should be shown.  And fix cases for 
Net-RID SP and DP.

    Via the direct Radio Frequency (RF) link between the UA and GCS:
    Command and Control (C2) flows between the GCS and UA such that either
    can communicate with the Net-RID SP.  For all but
    the simplest hobby aircraft, position and status flow from the UA to
    the GCS and on to the NetRID SP.  Thus via the Internet, through 
three distinct segments, Network
    RID information flows from the UAS to the Observer.

1.2.2.  Broadcast RID

    A set of RID messages are defined for direct, one-way, broadcast 
transmissions from
    the UA over Bluetooth or Wi-Fi.  These are currently defined as 
MAC-Layer messages.
    Internet (or other Wide Area Network) connectivity is only needed 
for UAS registry
    information lookup by Observers using the locally directly
    received UAS RID as a key.  Broadcast RID should be functionally
    usable in situations with no Internet connectivity.

And NO to Editor's note on NRID and BRID in one drawing.

Addressing Ed note after Fig 2:

    With Broadcast RID an Observer is limited to their radio "visible" 
airspace for UAS
    awareness and information.  With Internet queries using harvested 
RID, the Observer
    may gain more information about those visible UAS.

1.3.  Overview of USS Interoperability

This section just hangs there with no meaning.  Perhaps here is where 
NRID and BRID show up together by adding to Fig 3:

UAS-1 with NRID connection to USS-1
UAS-2 with BRID and Observer cloud to USS-1
UAS-3 with NRID connection to USS-2
UAS-4 with BRID and Observer cloud to USS-2

Then the following text below Fig 3:

Each UAS is registered to at least one USS.  With Net-RID, there is 
direct communication
between the UAS and its USS.  With Broadcast-RID, the UAS Operator has 
either pre-filed
a 4D space volume for USS operational knowledge and/or Observers can be 
providing
information about observed UA to a USS.  USS exchange information via a 
DSS so all USS
have knowledge about all activities in a 4D airspace.

1.4.  Overview of DRIP Architecture  {not misspell in title corrected here}

Fig 4 should have a UA1 and UA2 added.  UA1 should only show a link to 
UA1 Operator Pilot (no NetRID) and UA2 should show links to UA2 Operator 
and Internet.

Further, under "Operator" add text of GCS1 and GCS2.

This addresses Ed note 1.  The rest of the detail should be left out here.

And last 4 Ed notes in this section I will come back to at another go 
around...

More to follow.  Hopefully before our session.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 24 Nov 2020 00:05:45 -0500

More comments starting with sec 4

> Filename : draft-ietf-drip-arch-05.txt

After para 2 in Sec 4:

Design choices leading up to HHIT selection

For Remote ID to be trustworthy in the Broadcast mode, there MUST be an 
asymmetric keypair for proof of ID ownership.  The common method of 
using a key signing operation to assert ownership of an ID, does not 
guarantee name uniqueness.  Any entity can sign an ID, claiming 
ownership.  To mitigate spoofing risks, the ID needs to be 
cryptographically generated from the public key, in such a manner that 
it is statistically hard for an entity to create a public key that would 
generate (spoof) the ID.  Thus the signing of such an ID becomes an 
attestation (compared to claim) of ownership.

Remote IDs need a deterministic lookup mechanism that rapidly provides 
actionable information about the identified UA.  The ID itself needs to 
be the key into the lookup given the constraints imposed by some of the 
broadcast media.  This can best be achieved by an ID registration 
hierarchy cryptographically embedded within the ID.

The only (at time of Trustworthy Remote ID design) extant fixed length 
ID cryptographically derived from a public key are the Host Identity Tag 
(rfc7401), HITs, and Cryptographically Generated Addresses (rfc3972), 
CGAs.  Both lack a registration/retrieval capability and CGAs have only 
a limited crypto agility (rfc4982). Distributed Hash Tables have been 
tried for HITs (rfc6537); this is really not workable for a globally 
deployed UAS Remote ID scheme.

The original proposal for HITs included a registration hierarchy 
scheme.  This was dropped during HIP development for lack of a use 
case.  No similar mechanism is possible within CGAs.  It is a rather 
straightforward design update to HITs to Hierarchical HITs (HHITs) to 
meet the UAS Remote ID use case.

HHIT content

The HHIT needs to consist of a registration hierarchy, the hashing 
crypto suite information, and the hash of these items along with the 
underlying public key.  Additional information, e.g. an IPv6 prefix, may 
enhance the HHITs use beyond the basic Remote ID function (e.g. use in 
HIP, rfc7401).

The security of HHITs is achieved first through the cryptographic 
hashing function of the above information, along with a registration 
process to mitigate the probability of a hash collision (first 
registered, first allowed).

==================================

At this point I don't know what to do with some of the asterisk points 
in sec 4.  I have some...

Next on to sec 5!

Bob