Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt

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

Shuai and others,

Sorry for belated reply...

I just had a quick browse through the document and I am afraid that section 4, 5, and 6 are normative (they specify what to do) and it is really unusual in an architecture document (but there are exceptions). Moreover, it uses the normative BCP14 uppercase words “MUST”, “SHOULD”, etc. that should only apply in a normative “protocol action” document and would also require a BCP 14 template.

AFAIK, the HHIT part was added recently but it was done a little too fast. These sections should be about architecture and not about specifications or does the DRIP WG really want to have specifications in an architecture document ?

Sorry for not spotting this before: nothing negative about the architecture itself but more about following the right process to ease the publication process ;-)

Regards

-éric


From: Tm-rid <[e-mail]> on behalf of Daniel Migault <[e-mail]>
Date: Tuesday, 5 January 2021 at 00:01
To: shuai zhao <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Drip] New Version Notification for draft-ietf-drip-arch-07.txt

Hi Shuai,

Happy new year 2021!.

I have shortly reviewed the current version. I believe the document is heading in the right direction, but I believe interactions between the elements ( in a DRIP context) could be described in a simpler and easiest way. The way I see an architecture document is mostly exposing which boxes are involved and which box talks to which box. This includes the purpose of the communication as well as the protocol being used. I think a high level description could well fit in the architecture overview. The complex part is that here there are at least two main use cases, and many boxes - some more active than the others.
Currently we do have some additional description around  RID, and the registries. I believe that is appropriated but I believe these sections could be clarified and simplified.
I have included below some comments I had while reading the document - I hope this input will be helpful!

Yours,
Daniel


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

[...]

1.  Introduction

   This document describes a natural Internet and MAC-layer broadcast-
   based architecture for Unmanned Aircraft System Remote Identification
   and tracking (UAS RID), conforming to proposed regulations and
   external technical standards, satisfying the requirements listed in
   the companion requirements document [I-D.ietf-drip-reqs].

<mglt>
It is unclear to me the reason, if there is
any, to have "natural" being mentioned. I
think the idea is to mention that there is
the possibility that the UAS communicate
directly to the provider using IP
communications - which sounds natural.  As L2
and L3 communications are happening at
different layers, it also seems to me that
saying "Internet and MAC-layer" might not
clearly indicate there are two communications
that are envisioned. So maybe that could be
emphasized.

I am not having a strong opinion on how to
handle these comments. My main purpose is to
avoid to have the reader being sent off
track. I have the impression we could mention
the UAS needs to enable different
communications depending on its use case.

I think that the purpose of the architecture
description is not necessarily to match the
requirements. It seems to me the document is
mostly describing the entity involved. I
think here, given that the requirement
document has a huge description of the use
cases, we can state we assume the reader is
familiar with that document for the
description of the use cases.  The idea here
would be to tell the reader "the architecture
document may not be the one you should start
with" maybe have a look at the requirements
for the use cases.

</mglt>

   Many considerations (especially safety) dictate that UAS be remotely
   identifiable.  Civil Aviation Authorities (CAAs) worldwide are
   mandating Unmanned Aircraft Systems (UAS) Remote Identification
   (RID).  CAAs currently (2020) promulgate performance-based
   regulations that do not specify techniques, but rather cite industry
   consensus technical standards as acceptable means of compliance.

[...]

1.2.1.  Network RID

   A RID data dictionary and data flow for Network RID are defined in
   [F3411-19].  This data flow is from a UAS via unspecified means (but
   at least in part over the Internet) to a Network Remote ID Service
   Provider (Net-RID SP).  These Net-RID SPs provide this information to
<mglt>
I believe that "this information" refers to
the data. If so I am wondering if using the
same terminology may be clearer. I also
expect that the information refers to the
data being processed, so eventually, we may
clarify what this information is.

</mglt>
   Network Remote ID Display Providers (Net-RID DP).  It is the Net-RID
   DP that respond to queries from Network Remote ID clients (expected

<mglt>
I am wondering if the client are not here
designated or represented on the figure as
Observers. If so, we may clarify this. Note
that I think keeping client is fine, but we
may simply mention that  in the context of
the figure it is being represented as an
Observer.

</mglt>
   typically, but not specified exclusively, to be web based) specifying
   airspace volumes of interest.  Network RID depends upon connectivity,
   in several segments, via the Internet, from the UAS to the observer.

   The Network RID is illustrated in Figure 1 below:

               x x  UA
               xxxxx       ********************
                |   \    *                ------*---+------------+
                |    \   *              /       *  | NET_RID_SP |
                |     \  * ------------/    +---*--+------------+
                | RF   \ */                 |   *
                |        *      INTERNET    |   *  +------------+
                |       /*                  +---*--| NET_RID_DP |
                |      / *                  +---*--+------------+
                +     /   *                 |   *
                 x   /     *****************|***      x
               xxxxx                        |       xxxxx
                 x                          +-------  x
                 x                                    x
                x x   Operator (GCS)      Observer   x x
               x   x                                x   x

                                  Figure 1

   Via the direct Radio Frequency (RF) link between the UA and GCS,
   Command and Control (C2) flows between the GCS to the UA such that
   either can communicate with the Net-RID SP.  For all but the simplest
   hobby aircraft, position and status flow from the UA to the GCS and
   on to the Net-RID SP.  Thus via the Internet, through three distinct
   segments, Network RID information flows from the UAS to the Observer.

<mglt>
If correct, it might be worth mentioning that
the RF communication is not part of the RID
architecture.

</mglt>








Card, et al.               Expires 3 July 2021                  [Page 4]

Internet-Draft                  drip-arch                  December 2020


1.2.2.  Broadcast RID

   A set of RID messages are defined for direct, one-way, broadcast
   transmissions from the UA over Bluetooth or Wi-Fi.  These are
   currently defined as MAC-Layer messages.  Internet (or other Wide
   Area Network) connectivity is only needed for UAS registry
   information lookup by Observers using the locally directly received
   UAS RID as a key.  Broadcast RID should be functionally usable in
   situations with no Internet connectivity.

<mglt>
Though I understand that Broadcast RID do not
require Internet connectivity.  I also have
the impression that this interface will be
always on - even if there is internet
connectivity and a reliable communication to
the display provider.  The reason is - to me
- that the display provider can only provide
information that has been received from a
service provider. I can imagine a UAS not
providing its information to a SP and being
in the range of other UAS. If such situation
may happen, Broadcast is the backup
communication and probably closer to what is
happening on the ground. Of course a UAS not
broadcasting is another case and needs to be
"detected". I am wondering if that makes
sense, and it should probably be detailed in
the security consideration section.

</mglt>

   The Broadcast RID is illustrated in Figure 2 below.

                  x x  UA
                 xxxxx
                   |
                   |
                   |     app messages directly over
                   |     one-way RF data link (no IP)
                   |
                   |
                   +
                   x
                 xxxxx
                   x
                   x
                   x x   Observer's device (e.g. smartphone)
                 x   x

                                  Figure 2

   With Broadcast RID, an Observer is limited to their radio "visible"
   airspace for UAS awareness and information.  With Internet queries
   using harvested RID, the Observer may gain more information about
   those visible UAS.

[...]

1.4.  Overview of DRIP Architecture

   The requirements document [I-D.ietf-drip-reqs] also provides an
   extended introduction to the problem space, use cases, etc.  Only a
   brief summary of that introduction will be restated here as context,
   with reference to the general architecture shown in Figure 4 below.



<mglt>
There is always the question whether
something should be repeated or referenced. I
think it makes sense here to repeat.

</mglt>















Card, et al.               Expires 3 July 2021                  [Page 6]

Internet-Draft                  drip-arch                  December 2020


         General      x                           x     Public
         Public     xxxxx                       xxxxx   Safety
         Observer     x                           x     Observer
                      x                           x
                     x x ---------+  +---------- x x
                    x   x         |  |          x   x
                                  |  |
            UA1 x x               |  |  +------------ x x UA2
               xxxxx              |  |  |            xxxxx
                  |               +  +  +              |
                  |            xxxxxxxxxx              |
                  |           x          x             |
                  +----------+x Internet x+------------+
       UA1        |           x          x             |       UA1
      Pilot     x |            xxxxxxxxxx              | x    Pilot
     Operator  xxxxx              + + +                xxxxx Operator
      GCS1      x                 | | |                  x    GCS2
                x                 | | |                  x
               x x                | | |                 x x
              x   x               | | |                x   x
                                  | | |
                +----------+      | | |       +----------+
                |          |------+ | +-------|          |
                | Public   |        |         | Private  |
                | Registry |     +-----+      | Registry |
                |          |     | DNS |      |          |
                +----------+     +-----+      +----------+

                                  Figure 4

   Editor's note 1: the architecture may need more clarification, and
   address the following:

   *  connectivity requirements among UA, GCS, SP, DP (if necessary)

   DRIP will enable leveraging existing Internet resources (standard
   protocols, services, infrastructure and business models) to meet UAS
   RID and closely related needs.  DRIP will specify how to apply IETF
   standards, complementing [F3411-19] and other external standards, to
   satisfy UAS RID requirements.  DRIP will update existing and develop
   new protocol standards as needed to accomplish the foregoing.

   This document will outline the UAS RID architecture into which DRIP
   must fit, and an architecture for DRIP itself.  This includes
   presenting the gaps between the CAAs' Concepts of Operations and
   [F3411-19] as it relates to use of Internet technologies and UA
   direct RF communications.  Issues include, but are not limited to:

<mglt>
To me the complex part is that DRIP defines
an identifier, some frames to communicate
that RID over L2 as well as session
establishment protocols for internet
connectivity, DNS update protocols,....  I
tend to agree that one may have to point on
each interface what the focus of the DRIP
architecture is. But maybe there will be a
more straight forward way to do.

I think that this section should provide a
high level description on how each element
works between each other as well as their
relation to DRIP.

This section should also clarify:
how the UAS interact with the various
registries, USS. This includes the protocol
being used as well as the expected
provisioning and authentication. Does RID is
even used between the UAS and USS ?

how the observer observe the RID and proceed
to the request to the various registries.

Currently it seems to me the document is
mostly describing RID and interactions with
the registries. I think we need more to
provide a comprehensive architecture
document.

If the represented DNS does not contain any
DRIP information, and is only used for
standard DNS resolution, then, it seems not
necessary.



</mglt>


Card, et al.               Expires 3 July 2021                  [Page 7]

Internet-Draft                  drip-arch                  December 2020


   *  Mechanisms to leverage Domain Name System (DNS: [RFC1034]) and
      Extensible Provisioning Protocol (EPP [RFC5731]) technology to
      provide for private (Section 5.2) and public (Section 5.1)
      Information Registry.

   *  Trustworthy Remote ID and trust in RID messages (Section 4)

   *  Privacy in RID messages (PII protection) (Section 8)

      Editor's Note 2 : The following aspects are not covered in this
      draft, yet.  We may consider add sections for each of them if
      necessary.

   *  UA -> Ground communications including Broadcast RID

   *  Broadcast RID 'harvesting' and secure forwarding into the UTM

   *  Secure UAS -> Net-RID SP communications

   *  Secure Observer -> Pilot communications

[...]

3.3.  Claims, Assertions, Attestations, and Certificates

   This section introduces the meaning of "Claims", "Assertions",
   "Attestations", and "Certificates" in the context of DRIP.

   This is due, in part, to the term "certificate" having significant
   technologic and legal baggage associated with it, specifically around
   X.509 certificates.  These type of certificates and Public Key
   Infrastructure invokes more legal and public policy considerations
   than probably any other electronic communication sector.  It emerged
   as a governmental platform for trusted identity management and was
   pursued in intergovernmental bodies with links into treaty
   instruments.  As such the following terms are being used in DRIP.

<mglt>
I believe this section should mention the
rats architecture document and align to its
definitions. I have the impression we
slightly differ from their definitions and
would like as much as possible to avoid
having our owned definitions.

https://www.ietf.org/archive/id/draft-ietf-rats-architecture-08.html#name-artifacts
</mglt>

   Claims:

      For DRIP claims are used in the form of a predicate (X is Y, X has
      property Y, and most importantly X owns Y).  The basic form of a
      claim is an entity using a HHIT as an identifier in the DRIP UAS
      system.

   Assertions:

      Assertions, under DRIP, are defined as being a set of one or more
      claims.  This definition is borrowed from JWT/CWT.  An HHIT in of
      itself can be seen as a set of assertions.  First that the



Card, et al.               Expires 3 July 2021                  [Page 9]

Internet-Draft                  drip-arch                  December 2020


      identifier is a handle to an asymmetric keypair owned by the
      entity and that it also is part of the given registry (specified
      by the HID).

   Attestations:

      An attestation is a signed claim.  The signee may be the claimant
      themselves or a third party.  Under DRIP this is normally used
      when a set of entities asserts a relationship between them along
      with other information.

   Certificates:

      Certificates in DRIP have a narrow definition of being signed
      exclusively by a third party and are only over identities.

4.  HHIT for UAS Remote ID

   This section describes the basic requirements of a DRIP UAS remote ID
   per regulation constrains from ASTM [F3411-19] and explains the use
   of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6
   addresses and thereby a trustable Identifier for use as the UAS
   Remote ID.  HHITs self-attest to the included explicit hierarchy that
   provides Registrar discovery for 3rd-party ID attestation.

4.1.  UAS Remote Identifiers Problem Space

   A DRIP UAS ID needs to be "Trustworthy".  This means that within the
   framework of the RID messages, an observer can establish that the RID
   used does uniquely belong to the UA.  That the only way for any other
   UA to assert this RID would be to steal something from within the UA.

<mglt>
As in some cases I have the impression the
RID is owned by the GCS. I have the
impression UA should be the UAS. I would
maybe avoid to have the sentence That the
only way for other... but that is a personal
suggestion, so please feel free to do what
you believe is best to do.

</mglt>

   The RID is self-generated by the UAS (either UA or GCS) and
   registered with the USS.

<mglt>
I am wondering if that will be always the
case, and if manufacturer or user will not at
some point provision the UAS. It seems to me
safer to consider his description assumes or
consider the RID will be self generated.

Having read further down I think the document
contradict itself as both scenario are being
envisioned.
</mglt>

   Within the limitations of Broadcast RID, this is extremely
   challenging as:

   *  An RID can at most be 20 characters.

   *  The ASTM Basic RID message (the message containing the RID) is 25
      characters; only 3 characters are currently unused.

   *  The ASTM Authentication message, with some changes from [F3411-19]
      can carry 224 bytes of payload.

<mglt>
It is unclear to me what is the relation
between the first and second item and believe
that it should be clarified.  I have the
impression that - if correct - the following
may be clearer to the reader. The
communication of the RID to be trustworthy
needs to be associated with some
authentication. The ASTM defines the Basic
RID message that is expected to contained the
RID and the Authentication message that is
expected to contain the necessary
authentication information. The Basic RID
message has a maximum payload of 25 bytes and
the maximum size allocated by ASTM for the
RID is 20 bytes - as 3 bytes are left unused.
The authentication maximum payload is defined
to be 224 bytes.

</mglt>

   Standard approaches like X.509 and PKI will not fit these
   constraints, even using the new EdDSA [RFC8032] algorithm.

<mglt>
If the document mentions that X.509 is not
possible, I believe that more details should
be provided. I do not know the minimum X509
certificate but EdDSA keys are 32 (57) bytes,
and signatures are 64 (114) bytes.  This
seems to long for the RID to use the key
directly, but on the other hand public_key
and signature could be 32+64 = 98
(57+114=171) bytes which could fit in 224.
As there are also some other work on
certificate for IoT, I would rather not say
this is not possible and instead mention that
HIT is an example that address this.  To me,
but I might be wrong, it seems that the main
driver for HIT is that we could use the RID
to establish session between the RID owner
and some other parties.

</mglt>

An
   example of a technology that will fit within these limitations is an



Card, et al.               Expires 3 July 2021                 [Page 10]

Internet-Draft                  drip-arch                  December 2020


   enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401]
   introducing hierarchy as defined in HHIT [I-D.ietf-drip-rid]; using
   Hierarchical HITs for UAS RID is outlined in HHIT based UAS RID
   [I-D.ietf-drip-rid].  As PKI with X.509 is being used in other
   systems with which UAS RID must interoperate (e.g. the UTM Discovery
   and Synchronization Service and the UTM InterUSS protocol) mappings
   between the more flexible but larger X.509 certificates and the HHIT
   based structures must be devised.

   By using the EdDSA HHIT suite, self-assertions of the RID can be done
   in as little as 84 bytes.

<mglt>
I think that only apply with Ed25519, that is
20 + 64 with a spacial relation between the
RID and the public key. If so it might be
worth specifying that the example considers a
specific use case here Ed25519.

I believe also that a short description of
the HHIT may be clarifying.

</mglt>

Third-party assertions can be done in 200
   bytes.  An observer would need Internet access to validate a self-
   assertion claim.  A third-party assertion can be validated via a
   small credential cache in a disconnected environment.  This third-
   party assertion is possible when the third-party also uses HHITs for
   its identity and the UA has the public key for that HHIT

4.2.  HIT as A Trustworthy UAS Remote ID

   For a Remote ID to be trustworthy in the Broadcast mode, there MUST
   be an asymmetric keypair for proof of ID ownership.  The common
   method of using a key signing operation to assert ownership of an ID,
   does not guarantee name uniqueness.  Any entity can sign an ID,
   claiming ownership.  To mitigate spoofing risks, the ID needs to be
   cryptographically generated from the public key, in such a manner
   that it is statistically hard for an entity to create a public key
   that would generate (spoof) the ID.  Thus the signing of such an ID
   becomes an attestation (compared to claim) of ownership.

<mglt>
I think the evidence is composed of 2 claims,
the RID and the signature.  The attestation
seems to be the process of retrieving the
public key and checking the key, rid and
signature.  That said I am not entirely sure
I got it right either.

</mglt>

   HITs are statistically unique through the cryptographic hash feature
   of second-preimage resistance.  The cryptographically-bound addition
   of the Hierarchy and a HHIT registration process (e.g. based on
   Extensible Provisioning Protocol, [RFC5730]) provide complete, global
   HHIT uniqueness.  This is in contrast to general IDs (e.g. a UUID or
   device serial number) as the subject in an X.509 certificate.

4.3.  HHIT for Remote ID Registration and Lookup

   Remote IDs need a deterministic lookup mechanism that rapidly
   provides actionable information about the identified UA.  The ID
   itself needs to be the key into the lookup given the constraints

<mglt>
It might be clearer here to replace key by
input as to make sure the key mentioned has
no cryptographic properties.

</mglt>

   imposed by some of the broadcast media.  This can best be achieved by
   an ID registration hierarchy cryptographically embedded within the
   ID.







Card, et al.               Expires 3 July 2021                 [Page 11]

Internet-Draft                  drip-arch                  December 2020


   The original proposal for HITs included a registration hierarchy
   scheme.  This was dropped during HIP development for lack of a use
   case.  No similar mechanism is possible within CGAs.  It is a rather
   straightforward design update to HITs to Hierarchical HITs (HHITs) to
   meet the UAS Remote ID use case.

<mglt>
It is not so clear to me why CGA is mentioned
here. I do not see this as necessary - unless
I am missing something.

</mglt>

   The HHIT needs to consist of a registration hierarchy, the hashing
   crypto suite information, and the hash of these items along with the
   underlying public key.  Additional information, e.g. an IPv6 prefix,
   may enhance the HHITs use beyond the basic Remote ID function (e.g.
   use in HIP, [RFC7401]).

<mglt>
The paragraph above does not appear to me
very clear. The term "registration hierarchy"
may require some additional explanation. I
have the impression that it lists the
information that may be associated/registered
to the RID. If that is correct, I believe
this may be clearly stated.  We may also
clearly state what are the mandatory
information, at least the public key and the
nature of the RID - HHIT here.

</mglt>

   A DRIP UAS ID SHOULD be a HHIT.

<mglt>
It seems to me that this is one assumption of
this document. That said, I have the
impression the DRIP itself is simply used as
an input to retrieve some information so the
nature of the RID - in our case that it is
HHIT must be provided. It seems to me an
information as important as the public key.

</mglt>

  It SHOULD be self-generated by the
   UAS (either UA or GCS)

<mglt>
I believe that the RID is not itself
self-generated, but instead the keys. I am
not entirely convinced this is the right
place for having the information. Typically,
I am wondering how this would help impact the
registration or lookup based on the RID. I
think this is an important recommendation
though.  Maybe section 4.2 is more
appropriated for such comment.

</mglt>

and MUST be registered with the Private
   Information Registry identified in its hierarchy fields.  Each UAS ID
   HHIT MUST NOT be used more than once, with one exception as follows.

<mglt>
Maybe the Private Information Registry needs
to be better defined. I might have missed it,
but so far it seems that is the first time it
has been introduced in the document. More
specifically, I would expect that a clear
distinction between what is private and
public is made.

I also have the impression that the
architecture should enable a HHIT to be
updated for every flight, but I am not sure
that is something that is necessarily
mandatory. I think a MUST NOT statement is
here a bit too strong. Probably such
statement is more privacy consideration
statement. Similarly to my previous
statement, I have the impression that this
consideration is a bit out of scope of the
lookup section. I am wondering if having a
HHIT for RID section ( without lookup,
encryption,... ) should not be part of
section 4.2.

</mglt>

   Each UA MAY be assigned, by its manufacturer, a single HI and derived
   HHIT encoded as a hardware serial number per [CTA2063A].  Such a
   static HHIT SHOULD be used only to bind one-time use UAS IDs (other
   HHITs) to the unique UA.

<mglt>
It seems this section can be simplified. It
seems the text exposes how a UA provisioned
with one "static* or long term key can
generate ephemeral RIDs. I do not find
necessary to introduce HI for a long term
private key. In addition, HHIT derived from
that key do not seem to be the RID an
observer can observe, as only one-time RIDs
are used. As a result, it seems confusing to
me to use HHIT for long term secrets.  I am
wondering if the text is willing to say that
ephemeral HHIT (not based on the long term
public key) are redirected to the long term
RID or if any salt mechanism is used to
enable to generate multiple HHIT from one
public key.  I think the mechanism should be
further described, but it seems to me that
this is a mechanisms that could also be
reserved to the privacy consideration
section. In fact it may not deeply affect the
architecture itself as opposed to use the
architecture in place to provide privacy.
</mglt>

   Depending upon implementation, this may
   leave a HI private key in the possession of the manufacturer (see
   Security Considerations).

   Each UA equipped for Broadcast RID MUST be provisioned not only with
   its HHIT but also with the HI public key from which the HHIT was
   derived and the corresponding private key, to enable message
   signature.  Each UAS equipped for Network RID MUST be provisioned
   likewise; the private key SHOULD reside 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 MUST be provisioned with public keys of the UAS RID root
   registries and MAY be provisioned with public keys or certificates
   for subordinate registries.

   Operators and Private Information Registries MUST possess and other
   UTM entities MAY possess UAS ID style HHITs.  When present, such
   HHITs SHOULD be used with HIP to strongly mutually authenticate and
   optionally encrypt communications.












Card, et al.               Expires 3 July 2021                 [Page 12]

Internet-Draft                  drip-arch                  December 2020


4.4.  HHIT for Remote ID Encryption

   The only (at time of Trustworthy Remote ID design) extant fixed
   length ID cryptographically derived from a public key are the Host
   Identity Tag [RFC7401], HITs, and Cryptographically Generated
   Addresses [RFC3972], CGAs.  Both lack a registration/retrieval
   capability and CGAs have only a limited crypto agility [RFC4982].
   Distributed Hash Tables have been tried for HITs [RFC6537]; this is
   really not workable for a globally deployed UAS Remote ID scheme.

   The security of HHITs is achieved first through the cryptographic
   hashing function of the above information, along with a registration
   process to mitigate the probability of a hash collision (first
   registered, first allowed).

<mglt>
I am not convinced this section is needed.
</mglt>

5.  DRIP HHIT RID Registration and Registries

   The DRIP HHIT RID registration goes beyond what is currently
   envisioned in UTM for the UAS to USS registration/subscription
   process.

   UAS registries hold both public and private UAS information resulting
   from the UAS RID registration.  Given these different uses, and to
   improve scalability, security and simplicity of administration, the
   public and private information can be stored in different registries,
   indeed different types of registry.

5.1.  Public Information Registry

[...]

5.1.2.  Proposed Approach

   A DRIP public information registry MUST respond to standard DNS
<mglt>
It does not look to me appropriated to use
MUST. The architecture defines public
information being host in DNS seems to me
sufficient. It might be worth specifying if
DNSSEC is expected to be supported or not.

I do not also believe that having a proposed
approach is appropriated. It suggests that
the DRIP architecture has other alternatives.
I would simply describe what the DRIP
architecture considers.
</mglt>

queries, in the definitive public Internet DNS hierarchy.

It MUST
   support NS, MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR (the last per
   [RFC8005]) types.

<mglt>
It seems this goes a bit too far into the
specification. I do not see listing the
RRtypes being supported as necessary to be
mentioned in an architecture document. I also
question the relation to DRIP of NS or MX
RRtypes.

</mglt>

If a DRIP public information registry lists, in a
   HIP RR, any HIP RVS servers for a given DRIP UAS ID, those RVS
   servers MUST restrict relay services per AAA policy; this may require
   extensions to [RFC8004].  These public information registries SHOULD
   use secure DNS transport (e.g.  DNS over TLS) to deliver public
   information that is not inherently trustable (e.g. everything other
   than attestations).

<mglt>
If DNS over TLS is used, this also means that
the DNS infrastructure - resolvers cannot be
used. I potentially this this causing some
issues when no connectivity is provided. I
suspect that DNSSEC may be more appropriated
to re-use the DNS architecture and ease
adaptation to off line use cases.

</mglt>

5.2.  Private Information Registry

5.2.1.  Background

   The private information required for DRIP RID is similar to that
   required for Internet domain name registration.  This information
   SHOULD be available for ALL UAS, including those that only use
   Network RID.
<mglt>
I think it might worth clarifying how an
information accessible to ALL UAS is private.

</mglt>

A DRIP RID solution can leverage existing Internet
   resources: registration protocols, infrastructure and business
   models, by fitting into an ID structure compatible with DNS names.
   This implies some sort of hierarchy, for scalability, and management
   of this hierarchy.  It is expected that the private registry function
   will be provided by the same organizations that run USS, and likely
   integrated with USS.

5.2.2.  Proposed Approach

   A DRIP RID MUST be amenable to handling as an Internet domain name
   (at an arbitrary level in the hierarchy), MUST be registered in at
   least a pseudo-domain (e.g. .ip6.arpa for reverse lookup), and MAY be
   registered as a sub-domain (for forward lookup).  This DNS
   information MAY be protected with DNSSEC.  Its access SHOULD be
   protected with a secure DNS transport (e.g.  DNS over TLS).

<mglt>
It may not be very clear to me if private
informations are expected to be hosted. If
so, TLS might be mandatory and we me also
clarify how this information is expected to
remained cached in resolvers for example.

</mglt>















Card, et al.               Expires 3 July 2021                 [Page 14]

Internet-Draft                  drip-arch                  December 2020


   A DRIP private information registry MUST support essential Internet
   domain name registry operations (e.g. add, delete, update, query)
   using interoperable open standard protocols.  It SHOULD support the
   Extensible Provisioning Protocol (EPP) and the Registry Data Access
   Protocol (RDAP) with access controls.  It MAY use XACML to specify
   those access controls.  It MUST be listed in a DNS: that DNS MAY be
   private; but absent any compelling reasons for use of private DNS,
   SHOULD be the definitive public Internet DNS hierarchy.

<mglt>
I am not convinced that specifying the format
for access rules are necessary here, nor EPP.
It is unclear to me at that stage if the
registry is a DNS server or something else. I
have the impression the text should express
better the function of the Public and Private
registries.

</mglt>

The DRIP
   private information registry in which a given UAS is registered MUST
   be findable, starting from the UAS ID, using the methods specified in
   [RFC7484].  A DRIP private information registry MAY support WebFinger
   as specified in [RFC7033].

[...]

8.  Privacy for Broadcast PII

   Broadcast RID messages may contain PII.  This may be information
   about the UA such as its destination or Operator information such as
   GCS location.  There is no absolute "right" in hiding PII, as there
   will be times (e.g., disasters) and places (buffer zones around
   airports and sensitive facilities) where policy may mandate all
   information be sent as cleartext.
<mglt>
I do not believe cleartext is recommendable
in any way as it is subject to spoofing. The
minimum must be authenticated-only.

</mglt>

Otherwise, the modern general
   position (consistent with, e.g., the EU General Data Protection
   Regulation) is to hide PII unless otherwise instructed.  While some
   have argued that a system like that of automobile registration plates
   should suffice for UAS, others have argued persuasively that each
   generation of new identifiers should take advantage of advancing
   technology to protect privacy, to the extent compatible with the
   transparency needed to protect safety.




Card, et al.               Expires 3 July 2021                 [Page 17]

Internet-Draft                  drip-arch                  December 2020


   A viable architecture for PII protection would be symmetric
   encryption of the PII using a key known to the UAS and its USS.  An
   authorized Observer may send the encrypted PII along with the Remote
   ID (to their UTM Service Provider) to get the plaintext.
   Alternatively, the authorized Observer may receive the key to
   directly decrypt all future PII content from the UA.
<mglt>
I do have serious doubts this is viable, but
maybe I am missing the way it works.
Currently, it seems to me that an Observer
will get the key(s) used for the encryption
the communication between the UAS and its
USS, so it can decrypt the communication. If
my understanding is correct, I am wondering
how one can prevent the observer to inject
traffic to the USS on the behalf of the UA.

</mglt>



On Wed, Dec 30, 2020 at 9:02 PM shuai zhao <[e-mail]<mailto:[e-mail]>> wrote:
Dear DRIP,

We have just uploaded a new revision for DRIP architecture, which has a lots of good update:
· Added section 3.3 to explain what claims, assertion, attestations, and certification means in DRIP
· New section 4.1, which is old section 6, for a clean text organization
· Move crowd-sourced concept to a separated sec 6
· Lots of other details update across the draft.

For those of you who know the recent FAA final rules about RID, we will be addressing the necessary changes in the next revision.

Wish you all have a happy new year! See you in 2021...

-BR,
Shuai

On Dec 30, 2020, at 17:51, [e-mail]<mailto:[e-mail]> wrote:


A new version of I-D, draft-ietf-drip-arch-07.txt
has been successfully submitted by Shuai Zhao and posted to the
IETF repository.

Name: draft-ietf-drip-arch
Revision: 07
Title: Drone Remote Identification Protocol (DRIP) Architecture
Document date: 2020-12-30
Group: drip
Pages: 24
URL:            https://www.ietf.org/archive/id/draft-ietf-drip-arch-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-drip-arch/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch
Htmlized:       https://tools.ietf.org/html/draft-ietf-drip-arch-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-07

Abstract:
  This document defines an architecture for protocols and services to
  support Unmanned Aircraft System Remote Identification and tracking
  (UAS RID), plus RID-related communications, including required
  architectural building blocks and their interfaces.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


--
Tm-rid mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tm-rid


--
Daniel Migault
Ericsson