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

["shuaiizhao(Shuai Zhao)" <[e-mail]>]

Hi Bob and All, 


On 10/29/21, 12:41 PM, "Tm-rid on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> 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:

    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?

    Also we need to add that these SSD

    I like the term and should "upgrade" from just SDSP in crowd-source-rid?

    Should, can we, reference a source for this concept?

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).


    /s/attach/attack/  It was correct in -15.

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, [e-mail] 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tm-rid