Subject: [Drip] some comments on ietf-drip-reqs-03

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 21:08:33 -0400

I am reading these documents for the first time since the site meetings last
summer.  I have not read the architecture yet.
So far, I do not think the documents should be merged, but there is content
that I think is superfluous, and may be in the wrong place.

>   [F3411-19] specifies three UAS ID types:
>
>   TYPE-1  A static, manufacturer assigned, hardware serial number per
>           ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers"
>           [CTA2063A].
>
>   TYPE-2  A CAA assigned (presumably static) ID.
>
>   TYPE-3  A UTM system assigned UUID [RFC4122], which can but need not
>           be dynamic.
>
>   The EU allows only Type 1; the US allows Types 1 and 3, but requires
>   Type 3 IDs (if used) each to be used only once (for a single UAS

Who allows/requires Type-2?
(Some AD will ask that question ...)

>   specifies only how to get the UAS ID to the Observer; how the
>   Observer can perform these lookups, and how the registries first can
>   be populated with information, is unspecified.

Given that this is a requirements document in the IETF, the question about
how the lookups are performed/secured, and populated needs to clarified.
The possible answers are, I think:
  a) this work will occur within body XYZ (not the IETF)
  b) the fora for this work has not been determined, and the determination
     will be done by ABC (not the IETF)
  c) this is potential future work for the IETF, but is beyond this architecture

>   applications such as Detect And Avoid (DAA, which would impose
>   tighter latency bounds than RID itself) is an obvious possibility,

please avoid additional comments when (TLA). I suggest:

}   applications such as Detect And Avoid (DAA) is an obvious possibility,
}   Use of RID for DAA would impose tighter latency bounds than UAS RID
}   needs alone.

>   UA onboard RID devices are severely constrained in Cost, Size, Weight
>   and Power ($SWaP).  Cost is a significant impediment to the necessary

Since CSWP does not seem to spell $SWAP, the parenthical does not seem to fit
quite.  Until one realizes that Cost => $.  I suggest:

}   UA onboard RID devices are severely constrained in cost($), Size, Weight
}   and Power, known as: $SWaP.  Cost is a significant impediment to the necessary

I think that section 1 is pretty good.
If the requirements stopped there, that would be fine.

Terminology usually goes into Architecture document.
The terminology is rather extensive, and I doubt we need it all.
Maybe some of the less common aviation things could go into an appendix.
For instance: we probably don't need "SDO".
Meanwhile, "IFF" is not in the list.

Section 3 suggests multiple possible threats.  I wasn't sure why this section
was here at atll.  I would explicitely identify as your list of threats,
rather than calling it a problem space.

I think that 3.1 is architecture.

I think you might want a summary of existing work.
I think that 3.2 goes into that.

3.3 does not follow from 3.2.
Maybe 3.3 is requirements. So rather than:

   DRIP will focus on making information obtained via UAS RID
   immediately usable:

   1.  by making it trustworthy (despite the severe constraints of
       Broadcast RID);

say:
   A DRIP solution will focus on making the UAS RID trustworthy.
   REQ01. A DRIP solution will enable an Observer to verify if a UAS
          registered, even if the Observer has no active Internet connectivity.
...

   Any UA can assert any ID using the [F3411-19] required Basic ID
   message, which lacks any provisions for verification.  The Position/
   Vector message likewise lacks provisions for verification, and does
   not contain the ID, so must be correlated somehow with a Basic ID
   message: the developers of [F3411-19] have suggested using the MAC
   addresses, but these may be randomized by the operating system stack
   to avoid the adversarial correlation problems of static identifiers.

becomes something like:
   REQ0x: the DRIP solution will suggest a mechanism to correlate
          Position/Vector messages with UAS RID messages that does
          is tolerant of per Operation randomization of MAC addresses.

{Yes, operating systems random MAC addresses, but usually not within 2 hours.
It seems like a regulator could demand a single Operation use the same MAC addr}

   Further, [F3411-19] provides very limited choices for an observer to
   communicate with the pilot, e.g., to request further information on
   the UAS operation or exit from an airspace volume in an emergency.
   The System Message provides the location of the pilot/GCS, so an
   observer could physically go to the asserted GCS location to look for

this seems to suggest something like:
   REQ0n: the UAS RID will provide an identifier that can be used to
          securely index into a directory, in real time, that would
          provide for ... GCS/phonenumber/etc. to authorized entities.
{It seems like there could also be some kind of pseudonymous rendezvous,
that would allow friendly operators to discover each other}

Then you get into actual requirements, which I think you already got into.
GEN-1 contains at least four things. *message integrity/non-repudiation*,
*defense against replay attacks*, *defense against spoof*,
*connected to a sender public key* (GEN-3?), *Observer without Internet*

GEN-7 says nothing to me.  I don't know who the parties are for this QoS, and
      I don't think BT4 supports any things like "delivery latencies",
      so maybe you are talking about Network-RID?

Section 5.
   IETF traditionally operates assuming
   the source material for the standardization process is publicly
   available.  However, ASTM standards require a fee for download.

This doesn't belong in the document here, but it is important.
It should go into a charter revision, or some other WG plan.
I suggest that the process here is that the reqs and architecture are going
to quote and/or paraphrase as much as the ASTM specifications as required in
order to be stand-alone.  Or, ASTM can post the documents publically already.

I don't think section 5 is requirements.
I don't quite get why the discussion of ADS-B, etc.
I think that this has already been ruled out by ATSM, so that's really all
that matters.  If it needs to be covered, put it into an appendix.

The Security Considerations for a requirements document does not need to list
vulnerabilities like this, in my opinion.  Rather, it needs to simply repeat
which requirements are hard security requirements, and which ones may be less
important.

Privacy section is great.
The privacy section should point at a requirement somewhere, about how
"public safety personnel" are identified.  This document should not solve
that question, but say whether or not it (or some part of it) is in scope for
the architecture.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 23:26:09 -0400

Robert Moskowitz <[email-masked]> wrote:
    > Please review and comment on:

    >     draft-moskowitz-drip-uas-rid-03

I found section 5 to be too nebulous.
I guess this is discussion about possibilities... but which one do your
favour?  I found the DNSSEC comment odd. yes, 63M is a bit zone.
But, .com has 359M names, and it seems like the pieces under hhit.arpa could
be sharded quite easily.

    > This draft references:
    > The actual format of HHIT in:

    >     draft-moskowitz-hip-hierarchical-hit-05

    > Please comment on the division of the 96 bits allocation and 2 levels of
    > hierarchy.

okay.

I had to read through things a bit, including into RFC6890 to understand the
allocation rules for 2001::/23.  I was thinking, if there are 182 authorities
(if I heard that right, i.e. less than 2^8) in the world, maybe they could
all just ask IANA directly, leaving us with 16 more bits for the hash.   But
our process won't allow that.
I'm also a bit unclear about how much space they actually have here, since
ORCHID got a /28 here under 2001:00_00::/23, while 2001:db8::/32 is not
actually inside 2001:00_00::/23, if I'm doing my math right :-)

If you want more bits for the hash, then I would go for:
   *  28 bit IANA prefix
   *  12 bit Registered Assigning Authority (RAA)
   *  16 bit Hierarchical HIT Domain Authority (HDA)
   *  4 bit HIT Suite ID
   *  68 bit ORCHID hash

>   Suite ID can be used for HHITs, provided that the prefix for HHITs is
>   different from flat space HITs.  Without a unique prefix,
>   Section 4.1, additional HIT Suite IDs would be needed for HHITs.
>   This would risk exhausting the limited Suite ID space of only 15 IDs.

Either I don't understand, or this text is confusing.
I think the point is that if we don't have SuiteID, as we didn't for ORCHIDv1 (?)
then we'd have to go back to IANA for a new prefix every time we wanted a new
set of algorihms.