Subject: Re: [Drip] [draft-ietf-drip-arch-14] Section 5 Resolve Editor-note #16

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 21 Jul 2021 18:17:35 +0000

The following is the effort from Bob to address Editor note 16:

  *   Editor-note 16: Fundamentally disagree with not actually specifying an architecture in the DRIP Architecture document (From Stuart Card)

5.  DRIP Identifier Registration and Registries

   DRIP registries hold both public and private UAS information

   resulting from the DRIP identifier registration process.  Given these

   different uses, and to improve scalability, security, and simplicity

   of administration, the public and private information can be stored

   in different registries.  This section introduces the public and

   private information registries for DRIP identifiers.

5.1.  Public Information Registry

5.1.1.  Background

   The public registry provides trustable information such as

   attestations of RID ownership and registration with the HDA.

   Optionally, pointers to the repositories for the HDA and RAA implicit

   in the RID can be included (e.g., for HDA (Hierarchical HIT Domain

   Authority) and RAA (Registered Assigning Authority) HHIT|HI used in

   attestation signing operations).  This public information will be

   principally used by Observers of Broadcast RID messages.  Data on UAS

   that only use Network RID, is available via an Observer's Net-RID DP

   that would tend to directly provide all public registry information.

   The Observer may visually "see" these Net-RID UAS, but they may be

   silent to the Observer.  The Net-RID DP is the only source of

   information based on a query for an airspace volume.

5.1.2.  DNS as the Public DRIP Identifier Registry

   A DRIP identifier is amenable to handling as an Internet domain name

   (at an arbitrary level in the hierarchy, e.g. in .ip6.arpa).  Thus

   DNS can provide all the needed public DRIP information.  A

   standardized HHIT FQDN (Fully Qualified Domain Name) can deliver the

   HI via a HIP RR (Resource Record) [RFC8005] and other public

   information (e.g., RRA and HDA ptrs, and HIP RVS (Rendezvous Servers)

   [RFC8004]).  These public information registries can use secure DNS

   transport (e.g.  DNS over TLS) to deliver public information that is

   not inherently trustable (e.g. everything other than attestations).

5.2.  Private Information Registry

5.2.1.  Background

   The private information required for DRIP identifiers is similar to

   that required for Internet domain name registration.  A DRIP

   identifier solution can leverage existing Internet resources:

   registration protocols, infrastructure, and business models, by

   fitting into an ID structure compatible with DNS names.  The HHIT

   hierarchy can provide the needed scalability and management

   structure.  It is expected that the private registry function will be

   provided by the same organizations that run a USS, and likely

   integrated with a USS.  The lookup function may be implemented by the

   Net-RID DPs.

5.2.2.  EPP and RDAP as the Private DRIP Identifier Registry

   A DRIP private information registry supports essential registry

   operations (e.g. add, delete, update, query) using interoperable open

   standard protocols.  It can accomplish this by using the Extensible

   Provisioning Protocol (EPP [RFC5730]) and the Registry Data Access

   Protocol (RDAP RFC7480] [RFC7482] [RFC7483]).  The DRIP private

   information registry in which a given UAS is registered needs to be

   findable, starting from the UAS ID, using the methods specified in

   [RFC7484].

5.2.3.  Alternative Private DRIP Registry methods

   A DRIP private information registry might be an access controlled DNS

   (e.g. via DNS over TLS).  Additionally, WebFinger [RFC7033] can be

   deployed.  These alternative methods may be used by Net-RID DP with

   specific customers.

Best,
Shuai

On 7/14/21, 6:06 PM, "Robert Moskowitz" <[email-masked]> wrote:

    See the MLS arch doc as an example...

    https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/

    On 7/14/21 8:05 PM, Stuart W. Card wrote:

    > I typed "authentication" when I meant "architecture" in the line

    > marked below.

    > On 7/14/2021 11:40 AM, Stuart W. Card wrote:

    >> all --

    >> We need to resolve some fundamental conflicts/questions re: DRIP and

    >> its set of documents:

    >> (1) Are we trying to define _the_ DRIP architecture or _a_ DRIP

    >> architecture?

    >> (2) Are we trying to address, with this architecture, the broader set

    >> of purposes to which DRIP (originally Trustworthy Multipurpose RID)

    >> could be applied (a stretch goal), or only UAS RID (our burning need)?

    >> (3) If UAS RID only, are we trying to document the externally

    >> pre-defined architecture of UAS RID into which DRIP must fit, or a

    >> DRIP architecture to fit into the UAS RID architecture, or both?

    >> (4) What is the relationship between the architecture draft and Bob's

    >> UAS RID draft? If Bob's draft is defining how DRIP will be used for

    >> UAS RID, then what is the architecture draft supposed to define?

    >> IMO:

    >> (a) Bob's draft should be renamed either "The DRIP Entity Identifier"

    >> or "A HHIT Based DRIP Entity Identifier, and its scope narrowed to

    >> how HHITs can be used to satisfy the documented DRIP requirements,

    >> especially but not exclusively ID-*.

    >> (b) One of Adam's drafts (hopefully to be taken over by Michael

    >> Palage) should be renamed either "The DRIP Registries" or "DNS, EPP &

    >> RDAP based DRIP Registries".

    >> (c) Adam's other draft should be renamed either "The DRIP

    >> Authentication Protocol" or "A DRIP Authentication Protocol".

    > *** OOPS meant "architecture draft" below

    >> (d) The authentication draft should cite the other 3 and show how

    >> they fit together to satisfy the requirements.

    > *** OOPS meant "architecture draft" above

    >> Regardless of the answers to all the above questions, an architecture

    >> draft should be pushed forward rapidly that enumerates all the

    >> entities and interfaces among them that we need to satisfy the DRIP

    >> requirements sufficiently to meet the most urgent UAS RID needs not

    >> met by ASTM F3411 alone (namely, authentication and the handling of

    >> Session IDs), with sufficient commitment to detail (internally or by

    >> reference to other documents) to enable interoperability.