Subject: [Drip] Review #1 of draft-ietf-drip-reqs-03

From: Robert Moskowitz <[email-masked]>
Date: Thu, 16 Jul 2020 10:37:18 -0400

Definitions:

GRAIN - 'Putative' does not belong in this definition.  Best just strike 
it completely and not work out any other alternative term.

Altitude measurements (AGL, MSL, other?) - Do we say if these are 
Barometric or GPS based?  I think somehow this point needs to be made.

ASTM Messages defined -- Should you include which are flagged optional 
by ASTM?

4. Requirements

    PRIV-2  Encrypted Transport: DRIP MUST enable selective strong
            encryption of private data in motion in such a manner that
            only authorized actors can recover it.  If transport is via
            IP, then encryption MUST be end-to-end, at or above the IP
            layer.

What are the ends in "end-to-end".  I fear there is a rat-hole here.  
Maybe best to leave this clause out, or just:

If transport is via IP, then encryption MUST be at or above the IP layer 
(not only beneath IP).

Then for the rest of PRIV-2

Private data encryption MUST conform with CAA policies and procedures.  
That is there MAY be times and locations where encryption is NOT allowed 
and the UAS MUST be able to conform to these rules.

Bob

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Jul 2020 21:26:35 -0400

Hi,

Please find belong my review of the requirement draft. I think we are on
the right track. On thing I believe needs to be kept in mind is that
requirements will need to be checked by the solution defined in this WG. As
we are limited to the design of protocols requirements that cannot be met
by the protocol we define are - in my opinion - out of scope.

On reason I am mentioning this is that I recall the discussion during the
meeting on how to manage the leakage of the keys, the power of the
onboarded cpu. Though the discussion is interesting and passionate, it
might easily put us off tracks.

As always take my comments with a pinch of salt - especially after this
week ;-).

Yours,
Daniel

        Drone Remote Identification Protocol (DRIP) Requirements
                        draft-ietf-drip-reqs-03

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.
<mglt>
I also assume that the communication is
mostly the UA pushing information -
including  the RID -, but that is
unclear to me whether the provider is
not pulling instead.  </mglt>

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, although C2 link outages do
   occur).

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

<mglt>
When the UA has an internet connectivity
using the MAC address would not help.
Instead the MAC could be only used to
make the correlation in the case of
broadcast communication or communication
between the UA and the GCS. Is that
correct ?  If that is correct, what
correlation is proposed for a
connectivity over the Internet ?

In the case of radio communication using
MAC to correlate the messages, I have
the impression that the problem if the
MAC address is changed during an
established session between the UA and
the GCS - that is when RID and Position
are split over different sessions.
</mglt>

   The [F3411-19] 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 and far too short for conventional
   certificates.  The one-way nature of Broadcast RID precludes
   challenge-response security protocols (e.g., observers sending nonces
   to UA, to be returned in signed messages).  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, [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
   the remote pilot.  An observer with Internet connectivity could look
   up operator PII in a registry, then call a phone number in hopes
   someone who can immediately influence the UAS operation will answer
   promptly during that operation.

   Thus complementing [F3411-19] with protocols enabling strong
   authentication, preserving operator privacy while enabling immediate
   use of information by authorized parties, is critical to achieve
   widespread adoption of a RID system supporting safe and secure
   operation of UAS.

4.  Requirements

4.1.  General

   GEN-1   Provable Ownership: DRIP MUST enable verification that the
           UAS ID asserted in the Basic ID message is that of the actual
           current sender of the message (i.e. the message is not a
           replay attack or other spoof, authenticating e.g. by
           verifying an asymmetric cryptographic signature using a
           sender provided public key from which the asserted ID can be
           at least partially derived), even on an observer device
           lacking Internet connectivity at the time of observation.

<mglt>
the text looks to me quite hard to
parse. My reading of the text is that
the current sender of a message MUST be
identified as the sender of the Basic ID
message that has been sent in a previous
message.

I am wondering if that would not be
easier to say: The RID must be bound to
a public key. Any message ( including
the Basic ID message) must carry contain
a proof of ownership of the
corresponding private key as well as
anti replay mechanism.

Note that I am not sure that these words
seems simply easier to understand to me
because these are mine.

Now that I am reading GEN-2, I have the
impression the text I proposed covered
GEN-1 and GEN-2. In other words, the
message of GEN-1 seemed to be limited to
carry the RID.  I am unclear why
different requirements are needed.

I think that the sender should be
explicitly designated.  I suspect that
the sender may be the GCS or the UA. I
do have the impression that this might
lead to some ambiguity. It might be
better to say when the RID is sent by
the UAS....
</mglt>

Card, et al.             Expires 14 January 2021               [Page 18]

Internet-Draft                  DRIP Reqs                      July 2020

   GEN-2   Provable Binding: DRIP MUST enable binding all other F3411
           messages from the same actual current sender to the UAS ID
           asserted in the Basic ID message.
<mglt>
I am wondering if we are considering
other messages than F3411. If that is
not the case, I think the purpose of
DRIP is limited to the transport of the
messages, and as such our scope seems
independent of the message. I suggest
here we limit the scope to the
communication between UAS and
GCS/Provider/other UAS. I guess here we
are using the messages to define
interfaces.

While GEN -1 and GEN -2 requirement are
very generic and nice to set additional
requirements needs to be considers to
take into account either the imposed
format of the messages or the different
use cases we need to consider.  I see
requirement 5 at raising that concern
but I am wondering if that could be
articulated in a better way.  More
specifically, I understand the message
can carry the RID. In addition the
message can be send to the GCS via a
radio communication as well as through
the internet. This means that we may
have - as I imagine - RF/message or
IP/Transport/message.  Ig the bluetooth
or F3411 message format does not may
possible to have these mechanisms as
part of the message, it might be good to
specify that such mechanisms needs to be
performed at lower layers.

Again - I might have missed something,
but that seemed to be what GEN -5 was
derived from. And if that were correct,
I believe that these constraints should
be mentioned earlier.

</mglt>

   GEN-3   Provable Registration: DRIP MUST enable verification that the
           UAS ID is in a registry and identification of which one, even
           on an observer device lacking Internet connectivity at the
           time of observation; with UAS ID Type 3, the same sender may
           have multiple IDs, potentially in different registries, but
           each ID must clearly indicate in which registry it can be
           found.
<mglt>

The first sentence seems to me
ambiguous. "verification the UAS ID is
in a registry" make take several forms
such as the registry providing a proof
the UAS ID has been registered. I think
here we are simply mandating DRIP to
provide a way such that given a UAS ID
we are able to point to the registry. If
one needs a proof the RID is registered
we need the registry to provide such
proof. This, in particular imply to make
some mechanism that make a distinction
between a RID you are not allowed to
request information about - that is to
say all information is private - to a
RID that does not exist.

</mglt>

   GEN-4   Readability: DRIP MUST enable information (regulation
           required elements, whether sent via UAS RID or looked up in
           registries) to be read and utilized by both humans and
           software.
<mglt>

I think that utilized by human may need
to be clarified. First, I do not see
DRIP to define such information. I
expected these pieces to be defined by
regulators or other community. I do not
have a idea of the specifies of these
specifications. If they simply mention
name, address for example, we might
chose how to encode these pieces of
information. On the other hand, if they
mention it as a JSON file, we do have
less latitude. I do not know where we
are.

If the field is an address, I am
wondering what non utilized by a human
means. Typically, I assume a key is not
human readable because it does not tell
anything for a human. An address is
different, but I am not sure the raw
binary representation in punnycode or
UTF-8 is readable outside the use of
ascii. To extend this, whatever format
used, I expect  a conversion that will
make it readable to human when needed.

</mglt>

   GEN-5   Gateway: DRIP MUST enable Broadcast RID -> Network RID
           application layer gateways to stamp messages with precise
           date/time received and receiver location, then relay them to
           a network service (e.g.  SDSP or distributed ledger), to
           support three objectives: mark up a RID message with where
           and when it was actually received (which may agree or
           disagree with the self-report in the set of messages); defend
           against reply attacks; and support optional SDSP services
           such as multilateration (to complement UAS position self-
           reports with independent measurements).

<mglt>
"->'" needs to be clarified.  I suppose
that the gateway receives a bluetooth
message, the payload is carried over
internet. From that argument I
understand that we are using the IP
layer to perform the binding with the
key and provide the anti replay
protection.

I am trying to see how this positions to
GEN-1 and GEN-2 and it seems to me that
one issue may be that GEN-1 and GEN-2
concerns:

* the RID format forcing a sort of binding to a key
* the transport of a message that is not defined by drip
* the transport that is defined by drip

Given that F3411 defines the messages it
might be good to have different
requirements for the field (RID) of the
message - message that has been defined
for us - and the transport of the
message.

</mglt>

   GEN-6   Finger (placeholder name): DRIP MUST enable dynamically
           establishing, with AAA, per policy, E2E strongly encrypted
           communications with the UAS RID sender and entities looked up
           from the UAS ID, including at least the remote pilot and USS.

<mglt>
I do not see what the text adds to the
requirements of the UAS having mutual
authenticated communication.

</mglt>

   GEN-7   QoS: DRIP MUST enable policy based specification of
           performance and reliability parameters, such as maximum
           message transmission intervals and delivery latencies.

<mglt>
I am interpreting "delivery latency" as
the message rate. If that is correct, I
would recommend to evaluate if latency
is appropriated as I see it as a
physical limit that is hard to
configure. But that might be my own
vision.

</mglt>

   GEN-8   Mobility: DRIP MUST support physical and logical mobility of
           UA, GCS and Observers.  DRIP SHOULD support mobility of
           essentially all participating nodes (UA, GCS, Observers, Net-
           RID SP, Net-RID DP, Private Registry, SDSP).

   GEN-9   Multihoming: DRIP MUST support multihoming of UA and GCS, for
           make-before-break smooth handoff and resiliency against path/
           link failure.  DRIP SHOULD support multihoming of essentially
           all participating nodes.

<mglt>
I see mutlihoming involving multiple IP
addresses, and so it can be applied for
IP communications. In this case it seems
that UAS and GCS are using RF/IP
communications. I am wondering if that
wa i implied by multihoming.

</mglt>

Card, et al.             Expires 14 January 2021               [Page 19]

Internet-Draft                  DRIP Reqs                      July 2020

   GEN-10  Multicast: DRIP SHOULD support multicast for efficient and
           flexible publish-subscribe notifications, e.g., of UAS
           reporting positions in designated sensitive airspace volumes.

<mgtl>
This interface considered for the
multicast needs to be clarified. I think
that e.g. is

</mglt>
   GEN-11  Management: DRIP SHOULD support monitoring of the health and
           coverage of Broadcast and Network RID services.

4.2.  Identifier

   ID-1  Length: The DRIP (UAS) entity [remote] identifier must be no
         longer than 20 bytes (per [F3411-19] to fit in a Bluetooth 4
         advertisement payload).

   ID-2  Registry ID: The DRIP identifier MUST be sufficient to identify
         a registry in which the (UAS) entity identified therewith is
         listed.

   ID-3  Entity ID: The DRIP identifier MUST be sufficient to enable
         lookup of other data associated with the (UAS) entity
         identified therewith in that registry.
<mglt>
I understand the RID being sufficient to
reach the registries. ID-3 seems to b
erelated to the information provided by
the registries. As a resukt it does not
appears to be clearly in scope.

</mglt>
   ID-4  Uniqueness: The DRIP identifier MUST be unique within a to-be-
         defined scope.

<mglt>
looks to me insuffient. One may may
mention the most extreme case with maybe
a SHOULD somewhere.

I think I might have read ID4 as ID6 and
the scope here may be related to a pool
of rig generated by a common operator.

</mglt>

   ID-5  Non-spoofability: The DRIP identifier MUST be non-spoofable
         within the context of Remote ID broadcast messages (some
         collection of messages provides proof of UA ownership of ID).

   ID-6  Unlinkability: A DRIP UAS ID MUST NOT facilitate adversarial
         correlation over multiple UAS operations; this may be
         accomplished e.g. by limiting each identifier to a single use,
         but if so, the UAS ID MUST support well-defined scalable timely
         registration methods.

   Note that Registry ID and Entity ID are requirements on a single DRIP
   entity Identifier, not separate (types of) ID.  In the most common
   use case, the Entity will be the UA, and the DRIP Identifier will be
   the UAS ID; however, other entities may also benefit from having DRIP
   identifiers, so the Entity type is not prescribed here.

   Whether a UAS ID is generated by the operator, GCS, UA, USS or
   registry, or some collaboration thereamong, is unspecified; however,
   there must be agreement on the UAS ID among these entities.

4.3.  Privacy

Card, et al.             Expires 14 January 2021               [Page 20]

Internet-Draft                  DRIP Reqs                      July 2020

   PRIV-1  Confidential Handling: DRIP MUST enable confidential handling
           of private information (i.e., any and all information
           designated by neither cognizant authority nor the information
           owner as public, e.g., personal data).

<mglt>
I do not see such requirement matching
the design of our protocol and so maybe
out of scope.

</mglt>

   PRIV-2  Encrypted Transport: DRIP MUST enable selective strong
           encryption of private data in motion in such a manner that
           only authorized actors can recover it.  If transport is via
           IP, then encryption MUST be end-to-end, at or above the IP
           layer.  DRIP MUST NOT encrypt safety critical data to be
           transmitted over Broadcast RID unless also concurrently
           sending that data via Network RID and obtaining frequent
           confirmations of receipt.
<mglt>
I thinks that is implied by the mutually
authenticated (and encrypted)
communications.

</mglt>

   PRIV-3  Encrypted Storage: DRIP SHOULD facilitate selective strong
           encryption of private data at rest in such a manner that only
           authorized actors can recover it.
<mglt>
I am unsure this is something that will
be enforced by our protocol. As such I
would maybe considered this as out of
scope. Again just my thoughts.

</mglt>

   How information is stored on end systems is out of scope for DRIP.
   Encouraging privacy best practices, including end system storage
   encryption, by facilitating it with protocol design reflecting such
   considerations, is in scope.

On Thu, Jul 16, 2020 at 10:37 AM Robert Moskowitz <[email-masked]>
wrote:

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

-- 
Daniel Migault
Ericsson