Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-31

# Internet AD comments for {draft-ietf-drip-arch-24}
CC @ekline

## Nits

### Appendix B

* Consider: "manned aviation" -> "crewed aviation", or some similar construct

Thanks for this document. I have just a few comments.

1. This document repeatedly refers to "Observers", so capitalized as a proper noun. Presumably the capitalization implies that the authors think of Observers as a term of art, where Observers have some properties different from garden-variety lower-case observers, but the reader is left to guess what those properties might be.

Given the apparent importance of this distinction, it seems a definition should be supplied. Or, if there is in fact no important distinction between an Observer and an observer, lose the capitalization.

NITS and asides:

2. In §6, s/Broadcase/Broadcast/ (and does it really need to be capitalized?)

3. The crowdsourced RID idea is intriguing to be sure, but I'm a little baffled as to the motivation that would exist for people to opt in to such a scheme. I'm pretty sure that if my smartphone vendor popped up a dialog asking me to opt in to a UAV tracking scheme that doesn't benefit me in any meaningful way I'd click "no thanks" without a second thought. I'm curious whether there's some reason to think this will actually come to be a meaningfully widespread application, or if it's simply a neat idea that was fun to write down. (It's completely optional for you to answer this, it's only for my own curiosity.)

4. §8.1, s/wtih/with/

Thanks, this is really interesting work.

I'm a little concerned at the shepherd writeup, which claims the bulk of the review is being done by the co-authors and the chairs.  Where's the rest of the working group?  And given the content of Section 4.2.2, has anyone from REGEXT looked at this?

Also, question #8 on the writeup was not answered, although it's possible it was folded into the answer for #7.  This should be clarified if possible as it's important to have properly recorded.

I can't parse the second paragraph of Section 3.1.

In Section 3.2, should "trustworthy" be capitalized as it was in the prior section?  Also in Section 3.2, the sixth paragraph (starting "Ed25519") seems to be a bit mangled.

The SHOULD in Section 4.1.2 needs expansion.  Why might an implementer legitimately choose not to do what this says?  Or does this really need to be a MUST?

Thank you to Valery Smyslov for the SECDIR review.

Thanks for the revised text in -25 to -29, and the revisions in drip-auth and drip-registries referenced here.

Was a DISCUSS.  Per https://mailarchive.ietf.org/arch/msg/tm-rid/SSkTnaBgxkbw1yWyuciXyFTTa6M/:

> > ** Section 9
> >     Broadcast RID messages can contain Personally Identifiable
> >     Information (PII).  A viable architecture for PII protection would be
> >     symmetric encryption of the PII using a session key known to the UAS
> >     and its USS ...
> >
> > Per “A viable architecture ...”, I’m not sure how to read all the text after
> > the first sentence given this phrasing.  Is the rest of the text the official
> > “DRIP architecture” or an example? I’m assuming the former and believe it would
> > benefit from its own set of security considerations.  A few initial questions:
> >
> > -- Are there channel security requirements between the decryption oracle/key
> > escrow or distribution server/USS and the Observer?
> >
> > -- Is there a strong authentication/authorization model to gain services from
> > the USS?
> >
> > -- How does this oracle or key server approach work in the case an offline
> > observer?

> One proposal for this is
> 
> https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/
>
> It also deals with policy of use, like MUST NOT be used when there is no
> Internet for Authorized Observers to get keys.
> 
>This one gets into a bit of airspace politics.
>
> I think the text is as specific it can be without pointing to
> drip-operator-privacy.

You answered my question which is the this is a notional architecture so I won’t poke at it as being able to be implemented as is with the text.  I strongly recommend you drop most of this language and focus on describing the properties of the desired solution and how they need to be solved by operational deployments.  Defining notional parts of a candidate solution creates confusion on the bounds of the DRIP architecture.
From https://mailarchive.ietf.org/arch/msg/tm-rid/SSkTnaBgxkbw1yWyuciXyFTTa6M/:

> > ** Section 1.2.1.  This section discusses a “range up to approximately 1 km”,
> > notes “smartphones” as endpoints, and cites Bluetooth and WiFi as the wireless
> > technologies.  Even with line of sight, these seem like very long ranges
> > without specialized antennas (i.e., not on a smartphone).
>
> Actual field work has shown these distances achieved and there is a
> general push from many sources to use these numbers.

RF propagation is not my area of expertise.  I am surprised about a usable range of 1km for Bluetooth 5.* with commodity antennas. If you do have a reference, please include it.

> ** Section 2.1
>
>     DRIP could address standardization of
>     secure protocols between the UA and GCS (over direct wireless and
>     Internet connection), between the UAS and the Net-RID SP, and/or
>     between the Net-RID DP and Observer devices.
>
> Can this text be clarified?  Does this hypothetical make sense in an archival
> document?
>
> draft-moskowitz-drip-secure-nrid-c2

I don’t follow why a WG document is forward referencing an unadopted body of work.  I leave it to the WG to assess whether possible future DRIP work should be referenced here.



> > ** Section 4.2.  What information is being put into the Private Information
> > Registry?
>
> Policy of RAA and HDA. Covered in [I-D.ietf-drip-registries] , but
> generally out of scope as it will be up to each to decided what to
> require and then make available to authorized users.  You don't like
> what one RAA|HDA is asking of you, try another.

Recommend a specific pointer in drip-registries.

> > ** Section 8.1
> >
> >     Leakage of the private
> >     key either from the UA or GCS to the component manufacturer is a
> >     valid concern and steps need to be in place to ensure safe keeping of
> >     the private key.
> >
> > -- Section 3.2 seems to allow for the possibility that the manufacture is in
> > the key security boundary.  What is the implication of that design?
> >
> > -- In what way is it anticipated that a UA would leak a key back to the
> > manufacturer?
>
> Unfortunately we have seen this in part in the Ukraine.  Russia has been
> getting information on Ukrainian drones used from their Chinese
> manufacturers.  The young men that were hobbyists have found that this
> need to be very careful on what they do, or they get personally targeted.
>
>
> So do you trust your manufacturer?  DoD is not allowed to use DJI
> systems.  Well, I have heard they use the physical platform and put in
> their own controller systems.  DJI makes some of the best UAs...

Thanks.  Consider adding a call out for this supply chain issue.

Thank you for this document - I am currently traveling and so was not able to do as thorough a review as I would like - apologies for the somewhat rushed tone.

Thank you for writing this; I find "architecture" and "use-case" documents to be really helpful to understand how things are supposed to work, to get a "lay of the land", how various components are supposed to fit together, etc -- so, thank you for writing this.

Roman's security review is, as usual, very thorough -- I did have a few additional security thoughts / questions which I'm suspecting may already have been addressed, but which I missed.

1: It seems like a relay attack would be fairly trivial with the broadcast model -- either just record previous broadcasts from a drone in a similar position and just replay it, or if there are multiple drones in a similar area (they often seem to flock together near "interesting" events), simply have a receiver which records a broadcast and then replays it. The document does say (Sec 5): "Only sending the DET and a signature on frequently changing data that can be sanity-checked by the Observer (such as a Location/Vector message) proves that the observed UA possesses the claimed UAS ID." -- it seems like a note in the Security Considerations pointing back at this section would be good.

2: Based on how often keys are extracted even from devices which are "supposed" to be designed for security, I'm fairly sure that there will be trivial attacks for extracting private keys from small cheap drones and using them in "rogue" devices - the document does say "Leakage of the private key either from the UA or GCS to the component manufacturer is a valid concern and steps need to be in place to ensure safe keeping of the private key." but then "...  it is out of scope to deal wtih secure store for the private key." -- it feels to me like this is a fairly serious issue which is being hand-waved away with "it's out of scope..."

3: Nit: scope to deal wtih secure s/wtih/with/

4: "a revision to [F3411], currently in balloting (as of Oct 2021), adds type 4," -- presumably this has finished balloting - what was the outcome?

Thanks for working on this documentation. Special thanks to Kyle Rose for the TSVART review. 
Like Kyle I haven't picked up any TSV related issues. However, I have some comments which I believe will improve the document if addressed. See below --

- Section 1.1 : would be great to point to the 3GPP TR or TS for release 17 as well. An elaboration on how the UAS RID may be used as 3GPP CAA-level UAS RID would also be helpful here. Was this considered when the DRIP UAS RID designed so this is a direct match or the  3GPP needs some modification to adopt DRIP UAS RID. 

Overall, I like the idea of describing regulation bodies and other SDOs in this section. However, due to various level of description and intentions, it feels this section is not clear about what it want to achieve. 

- Section 1.4: Looking at the description it feels like the only reason figure 4 has two UASs is the V2V communication. It became a bit confusing for me to understand if there is any possibility of GCS in UAS1 sending command to UA in UAS2 or not. Or whether  GCS in UAS1 and UAS2 is representing same entity administrated by same  authority/controller. I went through the description with this confusion in mind and could not resolve it, may be I have missed it somehow. It will be great if this clarified in the description more vividly.

- Section 3: where is HHIT defined in  RFC 7401? or what is the purpose of referring to RFC 7401 in the beginning of the section?

- Where is the description of how to self-generate a DRIP Identifier? one possible answer could be  " Read this in section x of RFC xxx or in this document or read carefully here []", meaning I have surely missed something. But then I know where to read and how to generate the DRIP identifier.

[I support Roman's DISCUSS.]

Thanks to Kyle Rose for the TSVART review.

Hi,

Thanks for this document.

This is somewhat outside my area, and this is a minor comment, but I have to confess that I found it slightly harder to read, I think because it is fairly acronym heavy, and I wonder whether expanding out some of the less frequently used acronyms may end up making the document slightly more readable and approachable. 

Regards,
Rob