Re: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-data-only-ea-22: (with COMMENT)

[Brian Rosen <[e-mail]>]

All of your comments were addressed in -22

On Tue, Mar 10, 2020 at 1:53 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ecrit-data-only-ea-22: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for addressing my Discuss points!
>
> Original (presumed stale) comments preserved below.
>
> Introduction (and Abstract?)
>
>    medical monitors.  These messages may be one-shot alerts to emergency
>    authorities and do not require establishment of a session.  These
>    type of interactions are called 'non-interactive emergency calls'.
>
> Is this an existing/widespread definition or one new to this document?
> It may be worth providing a reference or rewording to clarify that it is
> a new definition.
>
> Section 2
>
>    CID is Content InDirection [RFC2392]
>
> The string "InDirection" does not appear in RFC 2392.
>
> Section 4.1
>
>    A CAP message may be sent in the initial message of any SIP
>    transaction.  However, this document only addresses sending a CAP
>    message in a SIP MESSAGE transaction for a one-shot, non-interactive
>    emergency call.  Behavior with other transactions is not defined.
>
> I suggest rephrasing to "A CAP message is sent in the initial message of
> a SIP transaction" to avoid potential concerns about inconsistency
> between "may be sent" and "not defined".
>
>    the CAP message.  Alternatively, the Call-Info header field may
>    contain a Content Indirect url [RFC2392] and the CAP message included
>
> nit: "Indirect" here vs. "InDirection" in Section 2
>
> Section 4.2
>
>       field.  If there is a need to copy the PIDF-LO structure
>       referenced by 'geolocation' to <area>, implementers must be aware
>
> When might this occur?  (It seems almost out of scope for this document
> based on my limited understanding.)
>
>       that <area> is limited to a circle or polygon, and conversion of
>       other shapes will be required.  Points SHOULD be converted to a
>       circle with a radius equal to the uncertainty of the point.  Arc-
>       bands and ellipses SHOULD be converted to an equivalent polygon.
>       3D locations SHOULD be converted to their equivalent 2D forms.
>
> nit: what is an "equivalent" polygon to an ellipse or arc-band?  In a
> mathematical sense it might mean "strict equivalence" or a large-n limit
> of an n-gon, or perhaps there is a corresponding uncertainty on the
> ellipse/arc-band that the polygon must stay within?  Rewording to
> "corresponding" might be an easy fix.
>
> Section 5.1
>
>    The 425 response code is a rejection of the request due to its
>    included alert content, indicating that it was malformed or not
>    satisfactory for the recipient's purpose.
>
>    A SIP intermediary can also reject an alert it receives from a User
>    Agent (UA) when it detects that the provided alert is malformed.
>
> (I assume there's an implicit "reject with this code" in here.)
>
>    It is only appropriate to generate a 425 response when the responding
>    entity has no other information in the request that is usable by the
>    responder.
>
> I'm not sure I'm parsing this sentence correctly.  My best guess is that
> it's saying "if there's anything in the request that you can respond to,
> don't use 425, even if there's some malformed CAP", but that doesn't
> really seem to be what the actual words are saying.  [Section 5.2 seems
> to support my guess.]
>
> Section 5.2
>
>       message-header   /= AlertMsg-Error
>                               ; (message-header from 3261)
>
> nit: mybe "RFC3261" to match the later comments?
>
>    wrong with the alert in the request.  This error code has a
>
> pedantic nit: the ABNF has 1-to-3-digit
>
>    standardized -- meaning an operator can change the strings -- but
>    MUST NOT change the meaning of the error code.  Similar to how RFC
>    3261 specifies, there MUST NOT be more than one string per error
>    code.
>
> RFC 3261 is ... pretty long.  Maybe throw us a bone with a section
> reference?  Also, I assume this "MUST NOT be more than one" is within a
> single AlertMsg-Error construction, since a truly global interpretation
> would mean that (since this document assigns strings) there cannot
> actually be changes made to the strings by an operator, which we just
> said is possible.
>
>    This document defines an initial list of AlertMsg-Error values for
>    any SIP response, including provisional responses (other than 100
>    Trying) and the new 425 response.  There MUST be no more than one
>    AlertMsg-Error code in a SIP response.  AlertMsg-Error values sent in
>
> Is this redundant with the "MUST NOT" I was asking about above?
>
>    Additionally, if an entity cannot or chooses not to process the alert
>    message from a SIP request, a 500 (Server Internal Error) SHOULD be
>    used with or without a configurable Retry-After header field.
>
> I don't think I understand when it's recommended to use 500 vs 425 (and
> vice versa).
>
> Section 7
>
> It's probably worth mentioning RFC 3428's note about:
>
> %  The size of MESSAGE requests outside of a media session MUST NOT
> %  exceed 1300 bytes, unless the UAC has positive knowledge that the
> %  message will not traverse a congestion-unsafe link at any hop, or
> %  that the message size is at least 200 bytes less than the lowest MTU
> %  value found en route to the UAS
>
> since that seems to still apply here.
>
> Section 8
>
> I'd consider using a more recent date than 2008-11-19 for the example
> <sent> time.  Also, why is the timestamp in the additional information
> 2010-11-14, almost two years later?
>
>                      <gml:pos>32.86726 -97.16054</gml:pos>
>
> Is that ... someone's house?  Maybe some different coordinates would be
> more appropriate.
>
> Figure 3 has "Content-Disposition: by-reference;handling=optional" but
> Figure 4 does not; is that significant?
>
> Section 9
>
>    In any case, for alerts initiated by sensors, the identity could play
>    an important role in deciding whether to accept or ignore an incoming
>    alert message.  With the scenario shown in Figure 1 it is very likely
>    that only authenticated sensor input will be processed.  For this
>    reason, it needs to be possible to refuse to accept alert messages
>    from an unknown origin.  Two types of information elements can be
>    used for this purpose:
>
>    1.  SIP itself provides security mechanisms that allow the
>        verification of the originator's identity, such as P-Asserted-
>        Identity [RFC3325] or SIP Identity [RFC8224].  The latter
>        provides a cryptographic assurance while the former relies on a
>        chain of trust model.  These mechanisms can be reused.
>
>    2.  CAP provides additional security mechanisms and the ability to
>        carry further information about the sender's identity.
>        Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP
>        documents.
>
> I'd consider adding a note that "the specific policy and mechanisms used
> in a given deployment are out of scope for this document", since the
> actual requirements in practice are so broad that we cannot really make
> detailed recommendations here.
>
>    In addition to the desire to perform identity-based access control,
>    the classic communication security threats need to be considered,
>    including integrity protection to prevent forgery or replay of alert
>    messages in transit.  To deal with replay of alerts, a CAP document
>    contains the mandatory <identifier>, <sender>, <sent> elements and an
>    optional <expire> element.  Together, these elements make the CAP
>    document unique for a specific sender and provide time restrictions.
>    An entity that has already received a CAP message within the
>    indicated timeframe is able to detect a replayed message and, if the
>    content of that message is unchanged, then no additional security
>
> Is *able* to detect, sure.  But is it recommended to do so?  Required?
>
>    vulnerability is created.  Additionally, it is RECOMMENDED to make
>    use of SIP security mechanisms, such as the SIP Identity PASSporT
>    [RFC8225], to tie the CAP message to the SIP message.  To provide
>
> Not required?  Please describe the risks of not doing so (whether
> directly or by reference).
>
>    protection of the entire SIP message exchange between neighboring SIP
>    entities, the usage of TLS is REQUIRED.
>
> Just to check: this is a 100% always, for everyone, "REQUIRED", not just
> in the subset of cases where protection of the entire exchange is
> desired?
>
>    Note that none of the security mechanism in this document protect
>    against a compromised sensor sending crafted alerts.  Privacy
>    provided for any emergency calls, including non-interactive messages,
>    is subject to local regulations.
>
> I suggest using "confidentiality protection" rather than "privacy"
> (unless it's a term of art in this field), to avoid confusion with...
> Privacy considerations for alerts (e.g., generated by sensors) that
> should be discussed.  RFC 7852 has some extensive privacy considerations
> that can be referenced to do the bulk of the work here.
>
> I'd also consider reiterating the opportunistic nature of cryptographic
> protection on emergency messages, as discussed in 6443 (since insecure
> emergency messaging is preferred to no emergency messaging), but this is
> not strictly speaking required.
>
> Section 12.2
>
> RFC 8225, as a RECOMMENDED feature, is more properly listed as a
> normative reference, per
>
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
>
>