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

["Card, Stu" <[e-mail]>]

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]> 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]>
> *Sent:* Monday, July 26, 2021 12:54 PM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Eric Vyncke
> (evyncke) <[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]>
> 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]> wrote:
>
> Hi Stu!
>
> Focusing on the DISCUSS only, please see inline ...
>
> > -----Original Message-----
> > From: Stuart W. Card <[e-mail]>
> > Sent: Thursday, July 1, 2021 3:44 AM
> > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail]
> ;
> > [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
> > 4947 Commercial Drive, Yorkville NY 13495
>
>