Subject: [Tm-rid] comments on draft-card-tmrid-uas-reqs-00

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Mar 2020 14:27:32 -0400

Hi,

Please find my comments regarding draft-card-tmrid-uas-reqs-00. I did not
necessarily repeated the comments from the use case document, so these
could be seen as additional comments. Overall I think the
requirements needs to be framed a little bit more to be considered in an
IETF context, I also think a diagram defining which entities are expected
to interact would be clarifying. Note that comments and questions are those
that came to me reading the document, so please take them as random
comments.

Please find my comments inline below. Note that as the WG has changed its
name, please change the name of the draft accordingly.

Yours,
Daniel

[...]
      Unmanned Aircraft System Remote Identification Requirements
                      draft-card-tmrid-uas-reqs-00
[...]

1.  Introduction

   ASTM International, Technical Committee F38 (UAS), Subcommittee
   F38.02 (Aircraft Operations), Work Item WK65041 (UAS Remote ID and
   Tracking), is a Proposed New Standard [WK65041].  It defines 2 means
 <mglt>
I am wondering if means is more appropriated that class ?
</mglt>
[...]

   [WK65041] specifies 3 UAS ID types.  Type 1 is a static, manufacturer
   assigned, hardware serial number per ANSI/CTA-2063-A "Small Unmanned
   Aerial System Serial Numbers" [CTA2063A].  Type 2 is a CAA assigned
   (presumably static) ID.  Type 3 is a UAS Traffic Management (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.
<mglt>
I am not sure I completely understand "once". Do we mean that Type 1 and
Type 2 not to be unique. Typically one ID assigned by a manufacturer to one
UA could be re-assigned to another UA while Type 3 must be unique.

I do not know what UUID for traffic management involve,  but I am wondering
if it characterizes something like a flight. In other words, a UA may use
multiple Type 3 RIDs over its lifetime.
</mglt>

   [WK65041] Broadcast
   RID transmits all information in the clear as plaintext, so Type 1
   static IDs enable trivial correlation of patterns of use,
   unacceptable in many applications, e.g. package delivery routes of
   competitors.

<mglt>
I suppose the same occurs for Type 2 that is presumably static. It might
also, worth explaining briefly in one line how Type 3 is not affected by
that privacy concern.

</mglt>

   [...]
   Although using UAS RID to facilitate related services, such as Detect
   And Avoid (DAA) and other applications of Vehicle to Vehicle or
   Vehicle to Infrastructure (V2V, V2I, collectively V2X)
   communications, is an obvious application (explicitly contemplated in
   the FAA NPRM), it has been ommitted from [WK65041] (explicitly
   declared out of scope in the ASTM working group discussions based on
   a distinction between RID as a security standard vs DAA as a safety
   application).  Although dynamic establishment of secure
   communications between the observer and the UAS pilot seems to have
   been contemplated by the FAA Aviation Rulemaking Committee (ARC), it
   is not addressed in any of the subsequent proposed regulations or
   technical specifications.

<mglt>I understand that RID are mostly expected to be used by DAA like
application, but the security associated to this application is out of
scope of WK6504. The same applies here regarding security. On the other
hand, while these security aspects may be independent, DAA like application
have real time requirements that needs to be reflected on the UAS RID
architecture/protocols.
</mglt>
[...]
   To accomplish this, TM-RID will liaise with
   SDOs and complement their standards with IETF work to meet this
   urgent need.  An Applicability Statement RFC for UAS RID, showing how
   to use IETF standardized technologies for this purpose, will be a
   central work product.  Technical Specification RFCs will address any
   necessary enhancements of specific supporting protocols.  TM-RID
   potentially could be applied to verifiably identify other types of
   registered things reported to be in specified physical locations, but
   the urgent motivation and clear initial focus is UAS.  Existing
   Internet resources (business models, infrastructure and protocol
   standards) should be leveraged.  A natural Internet architecture for
   UAS RID conforming to proposed regulations and external technical
   standards will be described in a companion UAS RID Architecture
   document;

<mglt>
I have the impression the text above might be related to the charter,
rather than the requirement document.
</mglt>

[...]

3.  UAS RID Problem Space

[...]

   Network RID from the UA itself (rather than from its GCS) and
   Broadcast RID require one or more wireless data links from the UA,
   but such communications are challenging due to $SWaP constraints and
   low altitude flight amidst structures and foliage over terrain.

<mglt>
At a very high level view, I am wondering if we could list the entities
involved. I believe that would be useful to have in order to derive the
requirements. So far I see:

* RID
* RID Service Provider (Manufaturer, CAA, )
* UA
* RID Display Provider ( which may include the Observer)
* UAS
* GCS
* ...

 An requirements are expected to mostly be associated to RID and UAS.

</mglt>

3.1.  Network RID

   Network RID has several variants.  The UA may have persistent onboard
   Internet connectivity, in which case it can consistently source RID
   information directly over the Internet.  The UA may have intermittent
   onboard Internet connectivity, in which case the GCS must source RID
   information whenever the UA itself is offline.  The UA may not have
   Internet connectivity of its own, but have instead some other form of
   communications to another node that can relay RID information to the
   Internet; this would typically be the GCS (which to perform its
   function must know where the UA is).  The UA may have no means of
   sourcing RID information, in which case the GCS must source it; this
   is typical in FAA NPRM Limited RID, which only needs to provide the
   location of the GCS (not that of the UA).

<mglt> If I understand correctly, FAA NPRM Limited RID is not an RID, but a
rule associated to the use of a RID. I am wondering if that is a FAA
terminology or our terminology as it might raised some confusion to call a
RID rule a RID.

In the case an Observer observes a UA and receives an RID, would that RID
be the one of the GCS or the of the UA ? While I should request my
information to the GCS, I do see the UA. I am wondering if there are any
other means to get the UA RID than from the UA itself.

Typically, I could imagine looking at a central service thaht shows me
which UA has requested an authorization to flight on the space I see. The
UA (or rather the GCS) and observer would have registered to that service.
Is that the purpose of the USS ?

</mglt>

[...]
   Network RID is the more flexible and less constrained of the defined
   UAS RID means, but is only partically specified in [WK65041].  It is
   presumed that IETF efforts supporting Broadcast RID (see next
   section) can be easily generalized for Network RID.

<mglt> In the case of Network RID, it seems to me that communication
between the UA and the GCS is *pre-established* and so the UA does not need
to authenticate itself to the GCS.  The communication of the position (for
example) from the UA to the GCS is outside our scope. What is not entirely
clear to me is whether the position associated to an UA (RID) is part of
the information provided by the UAS to an observer. In other words, I think
we need to specify whether dynamic information associated to an UA are in
our scope as well as how this information is carried to the UAS (from the
UA/GCS) as well as from the UAS to an Observer. I am also inclined to
believe that a single format may be agreed for broadcast as well as non
broadcast communication as that piece of information is using radio
communication at least on the first segment (UA-Observer or UA-GCS).
</mglt>

3.2.  Broadcast RID
[...]
<mglt>
I have one concern with Broadcast communication and identification of the
UA. If two UAs are flying together at very close distance), the
communication of the RID will let me know there is one legitimate UA and
one non legitimate UA. I am wondering how the observer will be able to
distinguish the position that correspond to each of the UA, and suspect
that identification will require a position information.

</mglt>

3.3.  TM-RID Focus

<mglt>
Note that TM-RID should now be replace dby DRIP.
</mglt>

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

<mglt>
I suspect it might be better to specify if the information can be static
and or dynamic.
</mglt>

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

   2.  second by enabling verification that an UAS is registered, and if
       so, in which registry (for classification of trusted operators on
       the basis of known registry vetting, even by observers lacking
       Internet connectivity at observation time);

   3.  third by enabling instant establishment, by authorized parties,
       of secure communications with the remote pilot.

   Any UA can assert any ID using the [WK65041] required Basic ID

<mglt>
This seems the first time Basic ID is introduced. I believe it would good
to define more precisely what the Basic ID is. Typically, I am wondering if
there are any specific constraints regarding the number of bytes. As
message has not been introduced when talking about the limits of RID, it
woudl also worth clarifying why message has been indicated here.

I am not entirely sure the suggestion is to use the MAC address as the
Basic ID

</mglt>
   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 [WK65041] 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.
   The [WK65041] optional Authentication Message specifies framing for
   authentication data, but does not specify any authentication method,
   and the maximum length of the specified framing is too short for
   conventional digital signatures, much less certificates.

<mglt>
I suppose the text wants to say that message length is too small for
certificates, but not necessarily too short to carry a signature. Am I
correct ?
</mglt>

   The one-way
   nature of Broadcast RID precludes any stateful security protocol.  An
   observer would be seriously challenged to validate the asserted UAS
   ID or any other information about the UAS or its operator looked up
   therefrom.

   Further, [WK65041] 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.
   An observer could physically go to the asserted GCS location to look
   for the remote pilot.

<mglt>
It is unclear how an observer of an UA could point to the GCS.

</mglt>

[...]
4.  Requirements

4.1.  General

   The general UAS RID requirements for tm-rid are to:

   1.  verify that messages originated from the claimed sender;

<mglt>
I think here "verify" needs to be more specific. It seems to me that
messages should be authenticated and that sufficient information be
provided to the receiver to identify the sender.

While this requirements seems common - thinking TLS/IPsec - the difficulty
probably comes from the constraints associated to the message itself and I
think these constraints needs to be mentioned in the requirements.

The term message is very generic and I am also wondering if the purpose is
to define a generic mechanism to secure messages or if there is only a
small sub set of messages. Another way to consider this question is whether
the message only carries an RID, a position, or if any other sort of data
could be carried using this message.
</mglt>

   2.  verify that the UAS ID is in a registry and identify which one;

<mglt>I think a technical requirement is to provide a globally reachable
repository of UAS IDs. This probably includes a system ( or scheme ) for
hierarchical or a flat model as well as a protocol to retrieve information
associated to that RID UAS.

It is unclear to me if the model is multiple information associated to UAS
RID that are considered as independent or if UAA can have different RIDs
and these needs to be linked together. I suspect the later in which case
this should be specified as a requirement.

If information can be dynamically provisioned, the system needs not only to
provide lookup but also the ability to provision information associated to
RIDs.
</mglt>

   3.  lookup, from the UAS ID, public information;

   4.  lookup, with AAA, private information, per policy;

<mglt>
I would see 3 and 4 as requiring the definition of authentication as well
as the definition ACL.
</mglt>

   5.  structure information for both human and machine readability;

<mglt>
There is also a requirement to define how the pieces of information are
linked together in order to defines a UAS database that fits the needs.
</mglt>

   6.  provision registries with static information on the UAS and its
       operator, dynamic information on its current operation within the
       UTM, and Internet direct contact information for services related
       to the foregoing;
<mglt>This sems to indicate there is no dynamic information such as for
example the position.
</mglt>

   7.  close the AAA-policy registry loop by governing AAA per
       registered policies and administering policies only via AAA;

   8.  dynamically establish, with AAA, per policy, E2E strongly
       encrypted communications with the UAS RID sender and entities
       looked up from the UAS ID, including the remote pilot and USS.

   It is highly desirable that Broadcast RID receivers be able to stamp
   messages with accurate date/time received and receiver location, then
   relay them to a network service (e.g. distributed ledger), inter alia
   for correlation to assess sender and receiver veracity.

<mglt>
I see the reason to have time stamps to present replay attack. Accuracy of
the time might be out of scope of our DRIP. Instead DRIP prevents the time
to be modified by a third party.
</mglt>

4.2.  UAS Identifier

   A tm-rid UAS ID MUST be:

   1.  20 bytes or smaller;

   2.  sufficient to identify a registry in which the UAS is listed;

<mglt>
It would probably worth mentioning the relation between the registry and
the RID. Typically, I suppose the registry provides the associated RID and
host the look up service. In other words, It is not possible for someone to
get an RID, chose the registry or hosting information service.
</mglt>

   3.  sufficient to enable lookup of other data in that registry;

   4.  unique within a to-be-defined scope;

Card, et al.              Expires 5 August 2020                [Page 11]

Internet-Draft                UAS RID Reqs                 February 2020

   5.  non-spoofable within the context of Remote ID broadcast messages
       (some collection of messages provides proof of UA ownership of
       ID).

-- 
Daniel Migault
Ericsson

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 18 Mar 2020 16:40:26 -0400

My comments and answers are inbetween Daniels.

On Wed, Mar 18, 2020 at 2:27 PM Daniel Migault <[email-masked]> wrote:

> I do not know what UUID for traffic management involve,  but I am
> wondering if it characterizes something like a flight. In other words, a UA
> may use multiple Type 3 RIDs over its lifetime.
> </mglt>
>

<atw>
Type 1 is unique to a UA and assigned by the manufacturer, it does not
change once it is set. It is the serial number of the UA.

Type 2 is a staticly assigned value by a CAA when you register your UA with
them. This is the "tail-number" of the UA if you are familiar with manned
aviation practices. It is directly linked to you (the pilot) and your CAA
assigned license number.

Type 3 is a UUID assigned by the UTM system for your UA on a given flight.
Depending on the scope of the UTM (and the RID Service Provider granting
it) this number could change with every flight or be static to you in that
system. So you are correct that a UA can see multipleType 3 RIDs over its
lifetime.

As an important side note the FAA NPRM mandates that in US airspace ONLY
Type 1 and Type 3 are to be used. Type 3 MUST be dynamic, changing every
flight, and be unique. For the EU they have mandated ONLY Type 1 is used
(this is no Type 2 or 3).
</atw>

> also, worth explaining briefly in one line how Type 3 is not affected by

<atw>
Noted.
</atw>

> have real time requirements that needs to be reflected on the UAS RID

<atw>
Agreed.
</atw>

>  An requirements are expected to mostly be associated to RID and UAS.

<atw>
Good call, a diagram showing their basic relationships would be good too.
</atw>

> <mglt> If I understand correctly, FAA NPRM Limited RID is not an RID, but
> a rule associated to the use of a RID. I am wondering if that is a FAA
> Is that the purpose of the USS ?

<atw>
Yes, 100% yes. I get confused myself and have to constantly be explicit to
understand what I mean. The FAA RID rules (Standard and Limited) use the
methods of Broadcast and Network.

In the case of an Observer sees a UA and receives RID that information
direct from the UA (via Broadcast RID). The other way to get RID
information is to query at RID Display Provider with location (such as a
bounding box) and it returns all data that matches the query you requested
and displays it for you. It also would keep that information to to date if
possible.

So you are 100% correct, that is the point of the USS (which can act as a
RID Service Provider and/or Display Provider).
</atw>

> to authenticate itself to the GCS..  The communication of the position (for

<atw>
You are correct that connection between UA and GCS is pre-established (it
nominally could be a 900 MHz control link).

According to the FAA NPRM in the Limited RID rule set (which only uses
Network RID) both the UA position information and the GCS position
information are sent to the RID Service Provider. The only time an Observer
would get this information is if they queried a RID Display Provider and
the UA/GCS is in the scope of the query.

I agree that a single format is a must. Is it the ASTM Broadcast RID
format, just without need link constraints? However in this links you
specified I believe ASTM puts them out of scope for their documents (not
that we can't).
</atw>

> that identification will require a position information.

<atw>
ASTM intends to use the MAC address for this.
</atw>

> I am not entirely sure the suggestion is to use the MAC address as the

<atw>
To state it here; Basic ID is one of the message types in ASTM Broadcast
RID. It has a constraint of 20 bytes for the UAS ID field.
</atw>

> certificates, but not necessarily too short to carry a signature. Am I

<atw>
Yes I would say so.
</atw>

>    communicate with the pilot, e..g.  to request further information on

> If information can be dynamically provisioned, the system needs not only
> to provide lookup but also the ability to provision information associated
> to RIDs.
> </mglt>
>

<atw>
Yes to this whole comment you made.
</atw>

> <mglt>This sems to indicate there is no dynamic information such as for

<atw>
For Broadcast RID there is a message type called "System" that is a static
message that contains the location information of the GCS at the moment of
take-off/provisioning for the flight.
</atw>

> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Mar 2020 21:19:40 -0400

Thanks for the responses. This was clarifying.
Yours,
Daniel

On Wed, Mar 18, 2020 at 4:40 PM Wiethuechter, Adam <
[email-masked]> wrote:

> Type 2 is a staticly assigned value by a CAA when you register your UA
> with them. This is the "tail-number" of the UA if you are familiar with
> manned aviation practices. It is directly linked to you (the pilot) and
> your CAA assigned license number.
>
>> While this requirements seems common - thinking TLS/IPsec - the
>> difficulty probably comes from the constraints associated to the message
>> itself and I think these constraints needs to be mentioned in the
>> requirements.
>>
>> The term message is very generic and I am also wondering if the purpose
>> is to define a generic mechanism to secure messages or if there is only a
>> It is unclear to me if the model is multiple information associated to
>> UAS RID that are considered as independent or if UAA can have different
>> RIDs and these needs to be linked together. I suspect the later in which
>> case this should be specified as a requirement.
>>
>> I see the reason to have time stamps to present replay attack. Accuracy
>> of the time might be out of scope of our DRIP. Instead DRIP prevents the
>> time to be modified by a third party.
>> </mglt>
>>
>>
>> 4.2.  UAS Identifier
>>
>>    A tm-rid UAS ID MUST be:
>>
>>    1.  20 bytes or smaller;
>>

-- 
Daniel Migault
Ericsson

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 23 Mar 2020 00:51:27 -0400

Thanks again Daniel for your reviews, my responses are interspersed.

On 3/18/2020 2:27 PM, Daniel Migault wrote:
> ...
> Please find my comments regarding draft-card-tmrid-uas-reqs-00. I did
> not necessarily repeated the comments from the use case document, so
> these could be seen as additional comments. Overall I think the
> IETF context, I also think a diagram defining which entities are
> expected to interact would be clarifying. Note that comments and
> questions are those that came to me reading the document, so please take
> them as random comments.
> 
> Please find my comments inline below. Note that as the WG has changed
> its name, please change the name of the draft accordingly.

Will do.

> I am wondering if means is more appropriated that class ?

<swc> Methods? Transports? </swc>

> Type 2 not to be unique. Typically one ID assigned by a manufacturer to
> one UA could be re-assigned to another UA while Type 3 must be unique.
> 
> wondering if it characterizes something like a flight. In other words, a
> UA may use multiple Type 3 RIDs over its lifetime.  
> </mglt>

<swc> "once" meaning in only one UAS "operation", i.e. flight. So yes:
under ASTM WK65041 (now ASTM 3411), more than one Type 3 ID _might_ be
used in the lifetime of an UA; and under the FAA NPRM, if a Type 3 is
used at all with a given UA, and that UA flies more than once, more than
one Type 3 _will_ be used in its lifetime (as many unique Type 3 IDs as
the number of UA flights). I can see that a lot of my prose requires
clarification. ;-) </swc>

> also, worth explaining briefly in one line how Type 3 is not affected by

<swc> Yes Type 2 is equally vulnerable, but presently neither EU nor US
regulators are allowing it, so I dropped it from discussion, which now
seems to me a mistake, as regulators might allow it in the future. The
single operation use of each Type 3 (in the US, at least) is what makes
it much less vulnerable to correlation attacks. </swc>

> hand, while these security aspects may be independent, DAA like
> application have real time requirements that needs to be reflected on
> the UAS RID architecture/protocols.
> </mglt>

<swc> Agreed, latency is a critical consideration, IMO for enabling
timely response to UAS RID by ground actors as well as for DAA. </swc>

> rather than the requirement document.

<swc> I am not yet wise in the ways of IETF so will gladly accept
guidance. :-) </swc>

>  An requirements are expected to mostly be associated to RID and UAS.

<swc> There are many entities: some physical (e.g. UA); some logical
actors (e.g. RID Display Provider); some passive information objects
(e.g. UAS identifier). We will need to structure the list accordingly.
BTW, one note for now: UAS = UA + GCS. </swc>

> <mglt> If I understand correctly, FAA NPRM Limited RID is not an RID,
> but a rule associated to the use of a RID. I am wondering if that is a
> FAA terminology or our terminology as it might raised some confusion to
> call a RID rule a RID.

<swc> Exactly! The FAA NPRM is all about rules: Limited RID is a set of
rules that apply to some UAS operated in a certain way; Standard RID is
a more demanding set of rules that apply outside the former case.
Limited RID specifies that Network RID is the general technical means to
be used; Standard RID requires both Network RID and Broadcast RID means
be used concurrently. This is indeed confusing, but it indeed is
externally defined terminology. We will just have to make it clear in
our Definitions section. </swc>

> In the case an Observer observes a UA and receives an RID, would that
> RID be the one of the GCS or the of the UA ? While I should request my

<swc> In all cases, the UAS ID received is that of the UA. If the
Observer is listening to Broadcast RID (implying, under the FAA NPRM,
that the UAS is operating under Standard RID rules), then both the UA
position and the GCS position will be reported. If the Observer is
listening to Network RID, there are 2 possibilities: if the UAS is
operating under Standard RID rules, again both positions will be
reported; if the UAS is operating under Limited RID rules, only the GCS
position will be reported. Even if the GCS is the proximate or even the
ultimate source of the RID information, the UAS ID is always that of the
UA. Obviously this requires clarification in the draft. </swc>

> which UA has requested an authorization to flight on the space I see.
> The UA (or rather the GCS) and observer would have registered to that
> service. Is that the purpose of the USS?
> </mglt>

<swc> That is the purpose of the Remote ID Service Provider function of
the USS to which that particular UAS operator has subscribed, but only
one of many purposes of that USS (which in turn is only one of many
USS). The "central service" to which you refer is a Display Provider
service, which may be provided by any of several entities (e.g. your own
USS if you are also an UAS operator, a Public Safety USS if you are a
fireman, etc.). </swc>

> between the UA and the GCS is *pre-established* and so the UA does not
> need to authenticate itself to the GCS..  The communication of the
> position (for example) from the UA to the GCS is outside our scope. What
> is not entirely clear to me is whether the position associated to an UA
> (RID) is part of the information provided by the UAS to an observer. In
> other words, I think we need to specify whether dynamic information
> associated to an UA are in our scope as well as how this information is
> carried to the UAS (from the UA/GCS) as well as from the UAS to an
> Observer. I am also inclined to believe that a single format may be
> agreed for broadcast as well as non broadcast communication as that
> piece of information is using radio communication at least on the first
> segment (UA-Observer or UA-GCS).
> </mglt>

<swc> In the US, whether UA position information is provided by Network
RID depends on whether the UAS is operating under Limited RID rules (no)
or Standard RID rules (yes). In any case, communication between the UA
and its GCS is outside our scope (even if the UA is the ultimate source
of its own position information and the GCS is relaying it into Network
RID). The elements of information and the ASTM 3411 RID message
structures are indeed the same regardless of Broadcast or Network, but
their outer encapsulation will differ (e.g. Bluetooth vs UDP/IP/LTE).

> 3.2.  Broadcast RID
> [...]
> <mglt>
> I have one concern with Broadcast communication and identification of
> the UA. If two UAs are flying together at very close distance), the

<swc> Yes! This is one of the problems we are trying to address. ASTM
3411 assumes Bluetooth 4.x MAC addresses will be used to correlate an ID
with a position/velocity; that seems terribly weak to us. BT5 and WiFi
allow for "Message Pack" structures that wrap both Basic ID and
position/velocity Vector messages in the same outer frame, avoiding the
need to correlate (guess). However, if 2 UA are very close, even with
such information, disambiguation may be infeasible due to imprecision of
position information. </swc>

> Note that TM-RID should now be replace dby DRIP.

<swc> Will do. </swc>

> I suspect it might be better to specify if the information can be static

<swc> That is actually a separate issue. I originally used the phrase
"immediately actionable", familiar in a military intelligence context,
but was told that was unfamiliar to others, so needed to use different
words. I substituted "immediately usable" but apparently it is still not
clear. The point is that a someone needs to be able to put the
information received via RID to immediate use: whether to establish
communications with the pilot, or to decide to shoot down the UA, or
whatever. ASTM 3411 information is not immediately actionable/usable:
first, it cannot be trusted, due to lack of local authentication means,
so so we might be shooting down an innocent UA (that was framed by a
spoofing transmitter) or failing to shoot down a hostile one; second,
all it enables is a lookup in a registry, with human eyeballs on text,
followed by indirect action, rather than immediate establishment of
communications with the remote pilot to query his intentions, demand
that he land, etc. </swc>

> This seems the first time Basic ID is introduced. I believe it would
> good to define more precisely what the Basic ID is. Typically, I am
> wondering if there are any specific constraints regarding the number of
> bytes. As message has not been introduced when talking about the limits
> of RID, it woudl also worth clarifying why message has been indicated
> here.  

<swc> Basic ID is one of the several UAS RID message types defined in
ASTM 3411. It provides only the UAS ID, of any of the 3 UAS ID Types.
The UAS ID itself is constrained to 20 bytes and fits in a message
structure of 25 bytes inside the 26 byte payload of a Bluetooth 4.x
frame. There is no intention, within ASTM or DRIP, to use a MAC address
as a UAS ID Type. The Basic ID message is introduced here, followed by
the Position/Velocity Vector message, to illustrate both the severe
length constraints on each, and show they are decoupled, creating the
BT4 MAC address correlation problem discussed under 3.2 above. </swc>

> certificates, but not necessarily too short to carry a signature. Am I

<swc> The message length is far too small for a conventional
certificate, and too small even for a conventional digital signature.
Bob's "new crypto" and Adam's authentication wrapper are designed to
enable strong signatures and certs to fit within these constraints. This
is enabled fundamentally by using a HHIT, which is a registered
identifier derived from a public key. </swc>

> It is unclear how an observer of an UA could point to the GCS.

<swc> Under the FAA NPRM, either Standard or Limited, whether using ASTM
3411 or any other acceptable means of compliance, whether Broadcast or
Network, the GCS position must be reported. An observer can then go to
that reported location to find the GCS and pilot. That is essentially
the only way (before DRIP) to establish communications between the
observer and the pilot (until the pilots returns to the office and can
be called at the phone # looked up in the registry). This is one of the
2 major "immediate actionability" advantages of DRIP as currently
conceived. </swc>

> provided to the receiver to identify the sender.

<swc> Yes. I used "verify" in the sense of Prover vs Verifier: the
sender must include authentication data in what is sent, to Prove its
identity; the receiver must do something with that authentication data
to Verify the actual sender is the claimed sender. </swc>

> itself and I think these constraints needs to be mentioned in the

<swc> Yes. The constraints are a major topic of the entire draft. I did
not recapitulate them as numbered requirements, as they are not what
DRIP must do for the user, but rather the context in which DRIP must do
it. If we want to number them, we can, but explicitly as constraints,
not as functional requirements. </swc>

> is to define a generic mechanism to secure messages or if there is only
> a small sub set of messages. Another way to consider this question is
> whether the message only carries an RID, a position, or if any other
> sort of data could be carried using this message.  
> </mglt>

<swc> ASTM 3411 defines only a small set of messages for UAS RID, with
very specific (down to the bit) message structures and interpretations.
Certainly other messages might usefully be sent through RID means. We
have attempted to define authentication methods that would work for any
short message fitting within the ASTM 3411 structure (25 bytes). </swc>

> hierarchical or a flat model as well as a protocol to retrieve
> information associated to that RID UAS.

<swc> That is the subject of requirements 3 & 4. </swc>

> case this should be specified as a requirement.

<swc> At any given time, one UAS ID = one UA. If Type 1, it lasts the
life of the UA. If Type 3, it lasts one operation (flight). Either way,
there is information associated with the UA that needs to be able to be
looked up from the current UAS ID. There is both static and dynamic RID
information in what is sent via RID means; only relatively static
information is looked up in the registry (it can change over the long
term, such as an operator's phone # changing, or an operator selling the
UA to another operator). </swc>

> to provide lookup but also the ability to provision information
> associated to RIDs.  
> </mglt>

<swc> RID registry information as such is relatively static (see
previous comment), but RID is increasingly seen as a key into UTM, which
contains highly dynamic information (flight plans, tracks, etc.).
Presumably the RID registry needs to contain static pointers to other
UTM entities that can provide that dynamic information on the identified
UA. </swc>

> I would see 3 and 4 as requiring the definition of authentication as
> well as the definition ACL.  
> </mglt>

<swc> I'm afraid I don't understand this comment. I would hope you don't
want to define a specific AAA policy within the requirements? Also
lookups by the public should not require any authentication by the party
doing the lookup: it is information that anyone should be able to
access. Authentication of the information itself, on the other hand, is
either covered under requirements (1) and (2) above (if it is
information sent via RID means), or is a responsibility of the registrar
(if it is information stored in the registry). Please explain what you
mean, thanks! </swc>

> linked together in order to defines a UAS database that fits the needs.

<swc> Certainly... but beyond being able to start with the UAS ID, use
that to uniquely identify the registry in which that UAS ID is listed,
then use the UAS ID again within the registry to look up whatever is
associated with that UA and its operator therein, doesn't this go beyond
our scope? </swc>

> <mglt>This sems to indicate there is no dynamic information such as for

<swc> There is dynamic information, including specifically position, but
that is not stored in the RID registry, it is transmitted via RID
(Broadcast and/or Network) by the UAS, and if Network RID is used, it is
stored temporarily in the USS. Of course, the registry function and the
USS function may well be performed by the same party, but that is a
business decision, not a technical requirement. The only dynamic
information that should be in the RID registry for a given UAS ID is a
pointer (unique key) to its current operation in the databases
maintained by its USS or other entities in the UTM system; this pointer
is likely to be the UAS ID itself (as a Type 3 UAS ID is assigned by the
UTM system). </swc>

> time to be modified by a third party.

<swc> Right, we have 3 purposes for time stamps. First, to say when the
UA was reported as being in a particular place. Second, to defend
against replay attacks. Third, to enable CS-RID, which is where any
accuracy requirement might come in; but we don't need to specify an
accuracy requirement for basic DRIP. </swc>

> ...
> the RID. Typically, I suppose the registry provides the associated RID
> and host the look up service. In other words, It is not possible for
> someone to get an RID, chose the registry or hosting information service.
> </mglt>

<swc> FAA NPRM Session ID = ASTM UAS ID Type 3 is UTM system assigned,
presumably by the specific USS being used by the operator of that UA for
that operation. If a UUID or HHIT is generated by the UA or its operator
under the assumption that a given registry will register it, then that
registry agrees to do so and signs a short cert attesting that it did,
and the registry is part of the UTM system, I think that counts. This is
the direction taken in the -arch draft and the encoding flowchart I
intend to present Wednesday. </swc>

Thanks again! Now I'll go through the rest of the thread on this, maybe
send a few more clarifications, then get some sleep before revving drafts.

- -- 
- -----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 23 Mar 2020 01:14:09 -0400

Again thanks and I'll intersperse further comments only where needed.

On 3/18/2020 4:40 PM, Wiethuechter, Adam wrote:
> My comments and answers are in between Daniels.
> 
> On Wed, Mar 18, 2020 at 2:27 PM Daniel Migault <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     [...]
>     between the UA and the GCS is *pre-established* and so the UA does
>     not need to authenticate itself to the GCS..  The communication of
>     the position (for example) from the UA to the GCS is outside our
>     scope. What is not entirely clear to me is whether the position
>     associated to an UA (RID) is part of the information provided by the
>     UAS to an observer. In other words, I think we need to specify
>     whether dynamic information associated to an UA are in our scope as
>     well as how this information is carried to the UAS (from the UA/GCS)
>     as well as from the UAS to an Observer. I am also inclined to
>     believe that a single format may be agreed for broadcast as well as
>     non broadcast communication as that piece of information is using
>     radio communication at least on the first segment (UA-Observer or
>     UA-GCS).
>     </mglt>
> 
> <atw>
> You are correct that connection between UA and GCS is pre-established
> (it nominally could be a 900 MHz control link).
> 
> information are sent to the RID Service Provider. The only time an
> Observer would get this information is if they queried a RID Display
> Provider and the UA/GCS is in the scope of the query.
> 

<swc> Correction: under FAA NPRM Limited RID rules, via Network RID,
only GCS position is sent; under FAA NPRM Standard RID rules, via both
Network RID and Broadcast RID, both GCS and UA position are sent. </swc>

>     3.2.  Broadcast RID
>     [...]
>     <mglt>
>     I have one concern with Broadcast communication and identification
>     of the UA. If two UAs are flying together at very close distance),
>     the communication of the RID will let me know there is one
>     legitimate UA and one non legitimate UA. I am wondering how the
>     observer will be able to distinguish the position that correspond to
>     each of the UA, and suspect that identification will require a
>     position information.
>     </mglt>
> 
> <atw>

<swc> Clarification: on Bluetooth 4.x, ASTM intends to use MAC addresses
to correlate the UAS ID (in the Basic ID message) with the
Position/Velocity (in the Vector message), which we find weak; on BT5
and WiFi, they intend to put those (and other) messages together in a
"Message Pack" all in one MAC layer frame. </swc>

>     certificates, but not necessarily too short to carry a signature. Am
>     I correct ?  
>     </mglt>
> 
> <atw>
> Yes I would say so.
> </atw>

<swc> Actually too short for certs or even sigs, unless you use
something like Bob's proposed "new crypto" together with a HHIT. </swc>

- --