Subject: Re: [Drip] Comments on Re: I-D Action: draft-ietf-drip-arch-16.txt

From: Robert Moskowitz <[email-masked]>
Date: Mon, 1 Nov 2021 08:33:29 -0400

I few more comments:

    [F3411-19] ASTM International, "Standard Specification for Remote ID
               and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>.

and

    [MAVLINK]  "Micro Air Vehicle Communication Protocol", 2021,
               <http://mavlink.io/>.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 2 Nov 2021 16:50:25 -0400

per F3411 reference.

Adam and I have worked out just to have [F3411] and leave off the ver 
(year) suffix.

And the year as n.d.

Yogi's famous quote about the lady singing, Adam and I are comfortable 
that any last minute changes will not impact the content put in for 
DRIP's needs in the next version due out sometime in the foreseeable future.

This cleans up references to ASTM in all of our documents.

Bob

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 9 Nov 2021 01:10:09 -0500

I would argue that a CS-RID SDSP is a subclass of Surveillance SDSP, but 
yes we want to be clear and consistent.

On 10/31/2021 5:41 PM, Robert Moskowitz wrote:
> Continuing...
> Sec 7
> In 1.3, we used: Surveillance Supplemental Data Service Provider
> We should follow through with that class of SDSP here or drop it in 1.3.
-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 9 Nov 2021 01:18:48 -0500

interspersed

On 10/29/2021 3:41 PM, Robert Moskowitz wrote:
> ...
> in 1.3:
> Where does "Surveillance Supplemental Data Service Provider (SDSP)" come 
> from?  It is only mentioned here.  I do not see this term in F3411-19 or 
> in WK63418 UAS Traffic Management (UTM) UAS Service Supplier (USS) 
> Interoperability Specification ver 0.4.1 (in ballot).  SDSP normally 
> means Supplemental Data Service Provider, so here it probably should be 
> SSDSP?
> ...
> I like the term and should "upgrade" from just SDSP in crowd-source-rid?
> Should, can we, reference a source for this concept?

Surveillance SDSP is a subclass of SDSP; the acronym refers to the 
larger class. SDSP can be found in the FAA UTM CONOPS. Surveillance SDSP 
is yet another ASTM work group item.

>     A DRIP registration process based on the explicit hierarchy within a
>     HHIT provides manageable uniqueness of the HI for the HHIT (defense
>     against a cryptographic hash second pre-image attach on the HHIT...
> /s/attach/attack/  It was correct in -15.

Sorry, I gave Shuai some suggested text to fix something else, but I 
inserted this typographical error in it. :-(

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 9 Nov 2021 05:57:11 -0500

On 11/9/21 1:18 AM, Stuart W. Card wrote:
>> Where does "Surveillance Supplemental Data Service Provider (SDSP)" 
>> come from?  It is only mentioned here.  I do not see this term in 
>> F3411-19 or in WK63418 UAS Traffic Management (UTM) UAS Service 
>> Supplier (USS) Interoperability Specification ver 0.4.1 (in ballot).  
>> SDSP normally means Supplemental Data Service Provider, so here it 
>> probably should be SSDSP?
>> ...
> larger class. SDSP can be found in the FAA UTM CONOPS. Surveillance 
> SDSP is yet another ASTM work group item.

Can we refer to a specific ASTM WK or similar?  Which subgroup of F38?

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 10 Nov 2021 20:56:17 +0000

Hi Bob and All, 

On 10/29/21, 12:41 PM, "Tm-rid on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    in 1.2:

    We just had fig 2 showing the Observer communicating with the Net-RID 
    DP, then say:

    It also prescribes data elements (in JSON) between Observer and USS

    I think that needs to be Net-RID DP.

    An Observer may well not have any relationship with any USS, though 
    Net-RID DP may well be a service provided within many USS systems.

Shuai/ Update to Net-RID DP, please speak up if this is wrong. 

    in 1.3:

    Also we need to add that these SSD

Shuai/ Stu will update this figure. I have add the editor-note as reminder

    Sec 3:

    Should this really be sec 2.4?  Its content is Definitions of terms.

    Seems I mentioned this in past reviews.

Shuai/ Ah... It is not. I don’t remember Back when, we agreed this to be a separated section.  I added the editor-note-7 as reminder to us to make a final agreement. 

    Sec 4.1:

    We are in a bit of a timing quandary, in that we can only reference 
    F3411-19, yet need to talk about the next version currently being 
    balloted.  This will either be F3411-21 or -22 (and interesting if they 
    quickly get the NEXT work item down and end up with TWO -22 versions!).

    Since we cannot reference ASTM draft documents (not unlike IEEE 802, 
    actually), how do we handle this?  I think we need some clarifying text 
    that the text here is about a draft version; we cannot provided any 
    information on its likelihood of being published.

    Also we may well have this RFC published prior to F3411-21!

    So:

    Broadcast RID, especially its support for Bluetooth 4, imposes severe
    constraints.  ASTM RID [F3411-19] allows a UAS ID of types 1, 2 and 3 of
    20 bytes; a revision to [F3411-19], currently in balloting (as of Oct 
    2021),
    adds type 4, Session IDs, to be
    standardized by IETF and other standard development organizations
    (SDOs) as extensions to ASTM RID, consumes one of those bytes
    to index the sub-type, leaving only 19 for the identifier (see
    Requirement ID-1).  Likewise, the maximum ASTM RID [F3411-19]
    Authentication Message payload is 201 bytes for most authentication
    types, but for type 5, also added in this revision, for IETF and other 
    SDOs to develop
    Specific Authentication Methods as extensions to ASTM RID, one
    byte is consumed to index the sub-type, leaving only 200 for DRIP
    authentication payloads, including one or more DRIP entity
    identifiers and associated authentication data.

Shuai/ Implemented as suggested in revision -17. Please speak up if you don’t agree. 

    4.2:

        A UAS equipped for DRIP Broadcast RID SHOULD be provisioned not only 
    with
        its HHIT but also with the HI key pair from which the HHIT was
        derived to enable message
        signature.  A UAS equipped for DRIP Network RID SHOULD be provisioned
        likewise; the private key resides only in the ultimate source of
        Network RID messages (i.e. on the UA itself if the GCS is merely
        relaying rather than sourcing Network RID messages).  Each Observer
        device SHOULD be provisioned either with public keys of the DRIP
        identifier root registries or certificates for subordinate
        registries.

    And I think that first "UAS" should be "UA".

Shuai/ Updated to "UA" in revision 17. 

        A self-attestation of a HHIT used as a UAS ID can be done in as
        little as 84 bytes, by avoiding an explicit encoding technology like
        ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This
        attestation consists of only the HHIT, a timestamp, and the EdDSA
        signature on them.

    I should point out that though this is true, Adam, Stu, and I are 
    debating the 'final' format (Adam 36 bytes to this).  I feel this is 
    correct for the architecture.

Shuai/ no actions.

        A DRIP registration process based on the explicit hierarchy within a
        HHIT provides manageable uniqueness of the HI for the HHIT (defense
        against a cryptographic hash second pre-image attach on the HHIT
        (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
        lookup of the HHIT into this registration data provides the
        registered HI for HHIT proof.  A first-come-first-serve registration
        for a HHIT provides deterministic access to any other needed
        actionable information based on inquiry access authority (more
        details in Section 5.2).

Shuai/ Updated now. thanks,

    You have parenthesis nested within parenthesis above and it is 
    confusing.  Instead:

        A DRIP registration process based on the explicit hierarchy within a
        HHIT provides manageable uniqueness of the HI for the HHIT.  This is 
    the defense
        against a cryptographic hash second pre-image attack on the HHIT
        (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
        lookup of the HHIT into this registration data provides the
        registered HI for HHIT proof.  A first-come-first-serve registration
        for a HHIT provides deterministic access to any other needed
        actionable information based on inquiry access authority (more
        details in Section 5.2.

Shuai/ Updated now. thanks,

    sec 4.4

    Minor edit:

        hierarchy within which is registered and a cryptographic hash of

    I think I got that right....

    At this point I am stopping and will pick up shortly with sec 5.

    Bob

Shuai/ Updated now. thanks,

    On 10/25/21 3:18 PM, [email-masked] wrote:
    > 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-16.txt
    > 	Pages           : 26
    > 	Date            : 2021-10-25
    >
    > Abstract:
    >     This document describes an architecture for protocols and services to
    >     support Unmanned Aircraft System Remote Identification and tracking
    >     (UAS RID), plus RID-related communications.  This architecture
    >     adheres to the requirements listed in the DRIP Requirements document.
    >

    -- 
    Tm-rid mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tm-rid

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:00:41 +0000

All Udpated. Thanks Bob. 

On 11/1/21, 5:34 AM, "Tm-rid on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    I few more comments:

    and

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:00:54 +0000

Sounds good to me. Updated in -17. 

Best,
Shuai

On 11/2/21, 1:51 PM, "Tm-rid on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    per F3411 reference.

    And the year as n.d.

    Bob

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:08:12 +0000

Thanks Bob, see reply inline. 

On 10/31/21, 2:42 PM, "Tm-rid on behalf of Robert Moskowitz" <[email-masked] on behalf of [email-masked]> wrote:

    Continuing with Sec 5.

    All is good IMO in sec 5.

    Sec 6.

    Para 2:

    Would a reader know what "offline or online" mean?  This is the first 
    and only use of both terms.  So we need to actually define them here.

    Also I do not think Broadcast RID needs to send messages that 
    authenticate all the way to the root.  This is rarely done in other 
    protocols.  Having something signed by the HDA and the HDA's HHIT,HI is 
    necessary, but sufficient along with access to a cache of the rest of 
    the hierarchy.  Similar to web browser CA root cache and DNS root cache.

    so

        An optimization of different DRIP Authentication Messages allows an
        Observer, without Internet connection (offline) or with (online), to be
        able to validate a UAS DRIP ID in real-
        time.  First is the sending of Broadcast Attestations (over
        DRIP Link Authentication Messages) containing the relevant registration
        of the UA's DRIP ID in the claimed Registry.  Next is
        sending DRIP Wrapper Authentication Messages that sign over
        both static (e.g. above registration) and dynamically changing data
        (such as UA location data).  Combining
        these two sets of information an Observer can piece together a chain
        of trust and real-time evidence to make their determination of the
        UAs claims.

Shuai/ Implemented as suggested . Please let me know if anyone has different option. 

    Sec 7

    And in 7.2 perhaps:

        A CS-RID SDSP should appear (i.e. present the same interface) to a
        Net-RID SP as a Net-RID DP.  A CS-RID SDSP aggregates and processes
        (e.g., estimates UA location using including using multilateration when
        possible) information collected by CS-RID Finders.

Shuai/ Implemented as suggested. However, we will update 1.3, so added a reminder in " Editor-note-8: double check above paragraph after editor-note-1 is resolved."

    Sec 8.

    One of the ways in which DRIP can enhance [F3411-19] with

Shuai/ Implemented as suggested

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

    And that completes my review.

    Bob

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 10 Nov 2021 21:10:59 +0000

I have added editor-note-1 and editor-note-8 as a reminder. Since we are going to update 1.3, we will have to come back to editor-note-8 to double check the language once more. 

Best,
Shuai

On 11/8/21, 10:10 PM, "Tm-rid on behalf of Stuart W. Card" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 10 Nov 2021 17:07:49 -0500

> Shuai/ Ah... It is not. I don’t remember Back when, we agreed this to be a separated section.  I added the editor-note-7 as reminder to us to make a final agreement.

The more I look at this, the more I feel that the current sec 3 should 
become sec 2.3.1

The contents of this section definitely constitute "Additional 
Definitions".  And all it does is introduce the terms with simple 
definition content.

Probably need AD/RFC-Editor to guide on this one.

Bob