Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

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

Romand and Stu

As I am obviously participating to the DRIP WG meeting and have a ‘private’ channel with Roman, then I will ping Roman when drip-reqs is discussed and if Roman is available, then I am sure that he will join :-)

Thank you all for being SO cooperative: the IETF spirit !

-éric

From: Tm-rid <[e-mail]> on behalf of "Card, Stu" <[e-mail]>
Date: Wednesday, 28 July 2021 at 14:53
To: Roman Danyliw <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Eric Vyncke <[e-mail]>
Subject: Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman --

I must defer to our WG chairs on agenda, but considering the importance of getting our requirements published (to guide our solution efforts & give ASTM, ICAO et al a doc to cite), I would think we would accomodate your joining us whenever you can take a few minutes to express your critical concerns with the draft. Thanks.

-- Stu

On Wed, Jul 28, 2021, 07:23 Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stu!

Sure.  I’m double booked during the DRIP meeting session today, but can step out and join the WG if there is a more precise time window.  When would be a good time (inside the Session II time window?

Roman

From: Card, Stu <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 26, 2021 12:54 PM
To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

Roman --

If you are available to join our DRIP session this Wednesday, you would be most welcome, as your DISCUSS is one of three pressing issues we currently have, and I do not wish to misrepresent your position. Thanks!

-- Stu

On Fri, Jul 23, 2021 at 5:49 PM Card, Stu <[e-mail]<mailto:[e-mail]>> wrote:
Roman et al --

What we mean is:

1) In any connectivity scenario where it is possible to satisfy the MUST requirements, they are indeed MUST requirements on the DRIP protocols themselves.

2) Scenarios will often arise where lower layer connectivity does not support the DRIP protocols fully accomplishing our goals. TCP does not provide reliable in-order stream delivery in cases where the only link goes down before the connection can be started, or goes down and stays down after connection establishment; TCP MUST requirements are not relaxed to SHOULD just because of this. DRIP is no different.

We merely highlight that UAS connectivity is highly variable, so DRIP protocols should (lower case) be designed with this in mind: to meet the requirements at all times & in all places where it would be possible for any protocol in those layers on those nodes to do so; and to be robust to the vagaries intrinsic to the environment.

I am very comfortable revising Section 6.

I am very uncomfortable weakening the numbered requirements, as that would let implementors off the hook for things that really are MUST for the DRIP protocols (when underlying connectivity permits). Also changing numbered requirements is not something I as editor really should do without concurrence of the DRIP WG, whose prior consensus was that these were MUST.

I am very open to text changes that clarify the intent without absolving implementors of meeting it.

Thanks for your consideration of all this.

On Fri, Jul 23, 2021, 16:39 Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stu!

Focusing on the DISCUSS only, please see inline ...

> -----Original Message-----
> From: Stuart W. Card <[e-mail]<mailto:[e-mail]>>
> Sent: Thursday, July 1, 2021 3:44 AM
> To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS
> and COMMENT)
>
> On 6/29/2021 5:31 PM, Roman Danyliw via Datatracker wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-drip-reqs-16: Discuss
> > ...
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/
> > ...
> Roman et al --
>
> Thanks again for the careful review. Rather than intersperse my responses in an
> email client direct quote of your message, for clarity, I exported it, trimmed it
> down, inserted my words, attributed your and my words explicitly to their
> respective authors, and then pasted it back in below.
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> ** Section 6.
>
> <rd>
> Thanks for enumerating these highly desirable security properties as part of
> DRIP.  A bit more clarifying language is needed to explain which
> communication paths in the DRIP architecture (Figure 3 and 4) have these
> properties and under what circumstances.  Section 4.1 and 4.2 seem specific to
> properties between particular parties or messages. Likewise, subsequent text in
> this section such as “… there may be caveats on the extent to which
> requirements can be satisfied…” seems to suggest these are not universal
> across the architecture.
> </rd>
>
> <swc>
> Right. I await the Document Shepherd's approval to upload my proposed
> revision 17, in which I have revised some of the text in Section 1.1 explaining
> Figure 1 (and correspondingly some text in Section 3.1 explaining Figure 3) as
> follows --
>
>   Note the absence of any links to/from the UA in the figure; this is
>   because UAS RID and other connectivity involving the UA varies.
>   Some connectivity paths do or do not exist depending upon the
>   scenario. Command and Control (C2) from the GCS to the UA via the
>   Internet (e.g., using LTE cellular) is expected to become much more
>   common as Beyond Visual Line Of Sight (BVLOS) operations increase;
>   in such a case, there is typically not also a direct wireless link
>   between the GCS and UA. Conversely, if C2 is running over a direct
>   wireless link, then typically the GCS has but the UA lacks Internet
>   connectivity. Further, paths that nominally exist, such as between
>   an Observer device and the Internet, may be severely intermittent.
>   These connectivity constraints are likely to have an impact, e.g.,
>   on how reliably DRIP requirements can be satisfied.
>
> With this caveat, our intention is to provide the desired properties, as specified
> by the numbered requirements in Section 4, wherever and whenever possible.
> With respect especially but not exclusively to Figure 4, GEN-1 and GEN-3 both
> explicitly demand "even on an Observer device lacking Internet connectivity at
> the time of observation."
> </swc>

Thanks for the revised -17 and the additional specificity it provides.  I'm still having difficulty reconciling what in fact is mandatory and which security properties DRIP is mandating.

(a) Section 4.1 and 4.2 makes normative (MUST-level ) requirements about security properties.  No concerns with these firm requirements.

(b) Section 6 appears to summarize these requirements into general principles.  Certainly more precise could be applied, but that's not my primary concern.

Despite these stated requirements, there is text that appears to caveat the mandatory nature of the "MUST"/"must" used in Sections 4.1, 4.2 and 6.   For example:

(c) Section 1.1. "These connectivity constraints are likely to have an impact, e.g., on how reliably DRIP requirements can be satisfied."

(d) Section 6. "Thus there may be caveats on the extent to which requirements can be satisfied in such cases, yet strenuous effort should be made to satisfy them, as such cases, e.g., firefighting in
   a national forest, are important."

The flexibility of (c) and (d) makes sense.  However, as a matter of consistency, if (c) and (d) are true, then the "MUSTs" in (a) and (b) are in fact "SHOULDs" because there are anticipated cases where these requirements are will not or cannot be satisfied (and that's intentional).

Put into narrative form:

-- In Section 6:

OLD:
It may be inferred from the general requirements (Section 4.1) for
   provable ownership, provable binding, and provable registration,
   together with the identifier requirements (Section 4.2), that DRIP
   must provide:

<list of properties>

NEW

It may be inferred from the general requirements (Section 4.1) for
   provable ownership, provable binding, and provable registration,
   together with the identifier requirements (Section 4.2), that DRIP
   aspires to provide:

<list of properties>

Particular use cases, operational conditions or deployment architecture patterns may prevent these security properties from being present.

-- Certain requirements of Section 4.* are ) s/MUST/SHOULD/

Regards,
Roman


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ** Abstract. "Complementing external technical standards as regulator-
> accepted means of compliance with UAS RID regulations..."
>
> <rd>
> I had trouble parsing this sentence.  Is it saying that DRIP is a complementing
> way to comply with UAS RID regulations?  Have “regulators”
> confirmed that compliance with DRIP satisfies “UAS RID regulations”?
> </rd>
>
> <swc>
> Regulators such as the FAA won't confirm anything about DRIP until we have
> published RFCs. However, FAA is collaborating with ASTM, and has expressed
> interest in DRIP solutions to some problems not being addressed by ASTM,
> especially how to issue single use Session IDs such that the FAA (only) can look
> up other information from them. I would prefer to keep the abstract very
> concise. Could this be addressed elsewhere in the document, if it needs to be
> addressed therein at all, rather than just in this email reply?
> </swc>
>
>
> ** Section 1.1.
>
> <rd> Is there a reference for IEEE 802.11 Beacon modes? </rd>
>
> <swc>
> IEEE 802.11 Beacon is a last minute addition to this draft, based on current
> ASTM work revising F3411 (which formerly required WiFi NAN) and recent EU
> standards actions. I stuck it in, without figuring out where, in the thousands of
> pages of IEEE 802.11 docs, I should cite something.
> Maybe someone more familiar with those could suggest a reference?
> </swc>
>
>
> ** Section 1.1.  Editorial.
>
> <rd>
> s/to authorities; enable authorities/to authorities; and enable authorities/
> </rd>
>
> <swc>
> Thanks for catching this! The grammar checking software didn't. Arghh!
> Usually my grammar is pretty good. I will fix it.
> </swc>
>
>
> ** Section 4.1.1.  GEN-2 and GEN-3.
>
> <rd>
> Since the name of the requirement is
> “provable binding” and “provable registration”, should the corresponding text
> convey the equivalently strong language.  For example:
>
> GEN-2
> s/MUST enable binding all/MUST enable the cryptographic binding of all/
>
> GEN-3
> s/MUST enable verification/MUST enable cryptographically-secure verification/
> </rd>
>
> <swc>
> I agree! I would be glad so to change the text of these two numbered
> requirements, if no one objects to my doing so?
> </swc>
>
>
> ** Section 4.1.1.
>
> <rd>
> Per Gen-6, it would be helpful to more clearly state the pair wise
> communications that will be secured.
> </rd>
>
> <swc>
> GEN-6 enumerates the endpoints _to which_ communications must be able to
> be established, but fails to specify any endpoints _from which_ they must be
> able to be initiated. This was intentional, as any party that obtains the UAS ID
> should be able to _request_ such establishment, yet only authorized parties
> ("with AAA") should be able to actually get it.
> So it is neither all nor only direct Observers. I would be glad to clarify this in
> 4.1.2 Rationale?
> </swc>
>
>
> ** Section 4.2.2.
>
> <rd>
> Per “In Network RID, it would be used by the application running over HTTPS
> (and possibly other protocols)”, to be clear, is HTTPS a requirement?
> </rd>
>
> <swc>
> ASTM F3411 specifies various HTTP methods for the interfaces among Network
> RID Service Providers (SP), Display Providers (DP) and the Discovery and
> Synchronization Service (DSS). It also specifies industry standard authentication
> and 128 bit or stronger encryption, but does not explicitly specify HTTPS, TLS or
> SSL. It implies but does not specify likewise for the DP to client interface. All
> implementations tested in FAA's UTM Pilot Project 2 used HTTPS. All this said
> as UAS RID context, HTTPS is not specifically a DRIP requirement. How much of
> this should be added to 4.2.2 Rationale?
> </swc>
>
>
> ** Section 4.3.1.
>
> <rd>
> Is there a clear definition somewhere of
> (a) private information; and
> (b) safety critical information?
> </rd>
>
> <swc>
> (a) Regulatory definitions vary by jurisdiction. In PRIV-1, DRIP defines private
> information very broadly as: "any and all information designated by neither
> cognizant authority nor the information owner as public". In the US, the FAA
> has specified that all the UAS RID information elements they require be
> broadcast for rule compliance are public and must be transmitted in cleartext.
> However, ASTM F3411 specifies the broadcast of additional information
> elements, not required by the FAA rule, which thus could be considered private
> (and eligible for encryption), if the UAS operator does not choose to disclose
> them publicly. Definition of private information is not really up to the DRIP WG,
> so however it may be defined in a given context, PRIV-4 states "DRIP SHOULD
> facilitate designation, by cognizant authorities and information owners, of
> which information is public and which is private". Also, we hope that a DRIP
> demonstration of effective means of maintaining operator privacy while
> ensuring that duly authorized parties can recover plaintext might encourage
> FAA and other regulators to allow selective encryption.
>
> (b) Safety critical information in UAS RID is not defined explicitly anywhere to
> the best of the authors' knowledge. It is implied by the FAA rule that the
> pilot/GCS location is safety critical: but this likely is due to neither the FAA rule
> nor the ASTM F3411 standard making provision for an Observer to contact the
> pilot in any manner other than physically going to the pilot's location; whereas
> DRIP GEN-6 Contact requires this.
> EU regulations seem to imply that even the operator's identity is safety critical,
> but if a policeman could read from an auto license plate the name of the
> registered owner of the car, it is not apparent how that could help him prevent
> an auto accident. Again, it is hoped that a DRIP demonstration of how privacy,
> safety and accountability can all be accomodated may lead to relaxation of
> privacy unfriendly regulations.
>
> How much of the above discussion merely needs to be archived as part of our
> IETF process, and how much needs to be added to 4.3.1 Rationale?
> </swc>
>
>
> ** Section 4.3.1.  PRIV-2.
>
> <rd>
> How would DRIP “know” that the local Observers are unlikely to be to be able
> to decrypt the information?
> </rd>
>
> <swc>
> If the UAS is not participating in UTM, an Observer would have no means of
> obtaining a decryption key or decryption services from a cognizant USS. If the
> UAS is participating in UTM, but has lost connectivity with its USS, then an
> Observer within visual LOS of the UA is also unlikely to be able to communicate
> with that USS (whether due to the USS being offline or the UAS and Observer
> being in an area with poor Internet connectivity). Either of these conditions
> (UTM non-participation or USS
> unreachability) would be known to the UAS. The possibility always exists that
> the Observer has lost Internet access despite being near a UAS with such
> access, but the possibility of a policeman being unable to get a forced entry
> warrant quickly due to a flat tire on the way to see a judge does not justify
> prohibiting locks on house doors. ;-) Would providing these examples, in 4.3.2
> Rationale, of how the UAS could reasonably assess that local Observers would
> be unlikely to be able to recover plaintext, suffice?
> </swc>
>
>
> ** Section 4.4.1.
>
> <rd>
> REG-2 makes a point of enforcing AAA but REG-1 explicitly states “MUST NOT
> restrict access to this information based on identity or role of the party
> submitting the query”.  Would this normative MUST per REG-1 rule out denial
> of service mitigation (e.g., rate limited high volume queries from an IP address)
> or attempts to scrape the entire database?
> </rd>
>
> <swc>
> The intent was to ensure that no member of the public would be hindered from
> accessing public information, while only duly authorized parties would be
> enabled to access private information. Mitigation of DoS and refusal to allow
> database scraping would be based on those behaviors, not on identity or role of
> the party submitting the query _per se_.
> These might be part of the information gathered on the misbehavior.
> Would adding this explanatory text to 4.4.2 Rationale suffice?
> </swc>
>
>
> ** Section 4.4.1.  REG-3.
>
> <rd> What is “Internet direct contact information”? </rd>
>
> <swc>
> A locator (e.g., IP address), or identifier (e.g., FQDN) that can be resolved to a
> locator, which would enable initiation of an end-to-end communication session
> using a well known protocol (e.g., SIP). Would adding this explanatory text to
> 4.4.2 Rationale suffice?
> </swc>
>
>
> --
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC  www.axenterprize.com<http://www.axenterprize.com>
> 4947 Commercial Drive, Yorkville NY 13495