Re: [Tsv-art] Tsvart last call review of draft-ietf-drip-arch-22

["Eric Vyncke (evyncke)" <[e-mail]>]

Kyle,

First, thank you for your technical review on this document. The more eyes on a document, the better the result.

Allow me to reply, as the responsible AD for DRIP, about your last point: whether this work should happen at the IETF.

As an IESG member, my view is that the IETF should welcome new pieces of work related to IP technologies. After two BoF, and a community consensus, the DRIP WG was officially formed (i.e., with the IETF community support). While the DRIP meetings do not attract hundreds of people, there are enough IETF engineers to make progress. So, in my opinion, this work can be done at the IETF (albeit other fora could have hosted it as the work is at the border of other fora -- like ICAO). The charter is also explicitly requesting the re-use of existing protocols as much as possible.

More specifically on this document (and I will let the WG chairs, the doc shepherd, the authors, and the WG to add more), it is an informational document (so no protocol action included) about architecture. So, it is expected (and even required) that such an architecture I-D does not specify anything.

Finally, other DRIP I-D, notably the RID one, will specify format and processing, i.e., real standards.

Thank you anyway for your review and your concern on getting the IETF efficient and lean,

Regards

-éric


-----Original Message-----
From: Kyle Rose via Datatracker <[e-mail]>
Reply to: Kyle Rose <[e-mail]>
Date: Tuesday, 5 April 2022 at 16:48
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Tsvart last call review of draft-ietf-drip-arch-22
Resent from: <[e-mail]>
Resent to: <[e-mail]>, <[e-mail]>, Erik Kline <[e-mail]>, <[e-mail]>, Eric Vyncke <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent date: Tuesday, 5 April 2022 at 16:48

    Reviewer: Kyle Rose
    Review result: Ready

    This document has been reviewed as part of the transport area review team's
    ongoing effort to review key IETF documents. These comments were written
    primarily for the transport area directors, but are copied to the document's
    authors and WG to allow them to address any issues raised and also to the IETF
    discussion list for information.

    When done at the time of IETF Last Call, the authors should consider this
    review as part of the last-call comments they receive. Please always CC
    [e-mail] if you reply to or forward this review.

    Status: Ready (with TSVART-nonspecific LC comments)

    I don't see any novel transport issues in this document: there is precedent for
    everything being proposed, with explicit references to existing RFCs.

    Putting my individual reviewer hat on, however:

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

    "Frequently changing" is not the right standard for preventing replay attacks:
    "novel" is. The idea is that the sender needs to sign data that has never been
    signed before and moreover that the receiver knows *a priori* would never have
    been signed by the key owner before. This is why, for instance, time codes are
    frequently used in such constructions: because time flows in only one
    direction, everyone has the ability to agree on what the current time is (even
    in a scenario in which participants are moving at relativistic speeds, a single
    reference frame can be chosen arbitrarily as the basis for the shared time
    scale), and no properly-functioning implementation would sign a future time
    code.

    > For that it MUST be registered (under DRIP Registries) and be actively used
    by the party (in most cases the UA).

    "Must" should probably be lowercase given that this is an informational
    document. Moreover, given the document overall takes the approach of making
    recommendations to others about how they can use IETF protocols in their
    technology space, and given that the IETF is not the protocol police, such
    recommendations really should be suggestions ("may be registered using
    such-and-such a protocol") rather than normative requirements.

    Nits aside, my main issue with this draft boils down to one question: why is
    this work happening at the IETF? In brief, the draft covers the following
    high-level recommendations:

    * Construction of an identifier for which only the owner can attest ownership
    (section 3)

    * Use of DNS as a registry for such identifiers (section 4)

    * Maintaining trust over time in messages from a given sender without on-going
    access to a trusted third-party (section 5)

    * Link-layer concerns (section 6)

    * Bootstrapping a persistent secure channel using identifiers currently trusted
    (section 7)

    None of these requires internet standards development unique to drone
    identification.

    It seems like the proper standards venue for this work is an aircraft or
    aerospace regulatory SDO, with liaisons from the IETF acting as subject matter
    experts for use of and integration with IETF protocols. If there is a broad
    category of users that heavily leverage internet technologies or that will
    likely impact protocol performance, there is precedent for the IETF forming a
    non-standards-developing operations group (akin to MOPS, a WG I co-chair)
    providing a forum within the IETF for the formulation and dispatch of
    requirements to appropriate function-specific WGs, both within and without the
    IETF, for further standards activity.

    Based on some early feedback I received, I want to make clear that I am *not*
    suggesting that the process for setting up a working group was not followed in
    the case of drip; rather, I am suggesting the process produced the wrong
    outcome. Working groups with very tangential relevance to the core mission of
    the IETF---development and maintenance of internet transports and their
    prerequisites---are a distraction that consumes valuable resources. While I
    risk sounding like Abe Simpson with this objection
    (https://www.youtube.com/watch?v=O5dmxBUbzBU), I know I am not the only one who
    has expressed concern over scope creep within the IETF, so taking this
    opportunity to highlight an example seemed worthwhile.