Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

[Az Mankin <[e-mail]>]

Hi, everyone,

I'd like to remind people that we use rough consensus, not perfect
unanimity, and we use a well defined process, including practical time
periods for our phases of last call.   We also care about "running code,"
and one thing that would be valuable for this last day of the last call is
to share info on state of implementation of these two specs.  This doesn't
mean they must be fully implemented and deployed, of course, but what types
of pragmatic or empirical tests have occurred so far?

I'm planning to request IETF Last Call this afternoon (Pacific Time) as
previously announced.  This will not launch an immediate IETF Last Call,
because there is first an AD Review, and I will work to present to Alyssa
what the remaining issues are in the shepherd's writeup.  I'm open to your
sending me text as input for the writeup.

Allison





On Tue, Oct 18, 2016 at 9:16 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >I think we can address any remaining comments as part of IETF Last Call.
>
> NO.
>
> We shall forward a document we are ok with. There most likely will be
> other issues and comments during IETF last call.
>
> Regards,
>
> Christer
>
>
> At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote:
>
> >  Hello,
> >
> >  first of all, I am participating in 3GPP CT1 meeting this week and I
> > have not have time to review changes between -015 and -018 properly.
> > Can we shift the deadline to next week?
> >
> >  I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE
> > 15, ISSUE 16, ISSUE 17, ISSUE 19.
> >
> >  On the remaining issues:
> >
> >>  >  ISSUE 2:
> >>  >
> >>  >  section 3 - level of technical detail of the last paragraph of  >
> >> section 3 does not fit with level of technical detail of the
> >> remaining  > text of section 3.
> >>
> >>  Intermediate paragraphs were added in version 17.
> >
> >  I still believe that section 3 contains different types of information:
> >  Type1: generic overview of the eCall requirements, existing solutions,
> ...
> >  Type2: information about the draft
> >
> >  It would be better to split those to separate sections.
>
> Can you elaborate on what the problem is?
>
> >
> >>  >  ISSUE 4:
> >>  >
> >>  >  section 4, "   This document registers the 'application/
> >>  >     emergencyCallData.eCall.MSD+per' MIME Content-Type to enable
> the MSD
> >>  >     to be carried in SIP."
> >>  >
> >>  >  There is no MIME Content-Type registry. "MIME Content-Type" ->
> >> "MIME type"
> >>  >
> >>  >  Same in other places of the document.
> >>
> >>  Corrected "content type" to "media type".
> >
> >  I can still see a few occurences of "content type" in -018 - e.g.
>
> Thanks, I'll do a grep.
>
> >
> >  ---------
> >        Security considerations: This ****content type**** is designed to
> carry
> >        vehicle and incident-related data during an emergency call.  This
> >        data contains personal information including vehicle VIN,
> >        location, direction, etc.  Appropriate precautions need to be
> >        taken to limit unauthorized access, inappropriate disclosure to
> >        third parties, and eavesdropping of this information.  In general,
> >        it is acceptable for the data to be unprotected while briefly in
> >        transit within the Mobile Network Operator (MNO); the MNO is
> >        trusted to not permit the data to be accessed by third parties.
> >        Sections 7 and Section 8 of [RFC7852] contain more discussion.
> >  ---------
> >  and
> >  ---------
> >     The metadata/control block is designed for use with pan-European
> >     eCall and also eCall-like systems (i.e., in other regions), and has
> >     extension points.  Note that eCall-like systems might define their
> >     own vehicle data blocks, and so might need to register a new INFO
> >     package to accomodate the new data ****content type**** and the
> metadata/
> >     control object.
> >  ---------
> >  and
> >  --------
> >           This ****content type**** carries metadata and control
> > information and
> >           requests, such as from a Public Safety Answering Point (PSAP)
> >           to an In-Vehicle System (IVS) during an emergency call.
> >  --------
> >
> >>  >  ISSUE 6:
> >>  >
> >>  >  section 6 - "An MSD or a metadata/control block is always
> >> enclosed in  > a multipart
> >>  >     body part (even if it would otherwise be the only body part in
> the
> >>  >     SIP message)." - which multipart MIME type is meant?
> >>  > multipart/mixed or multipart/alternative or ....
> >>
> >>  We do not need to specify that in this text.
> >
> >  IMO, we need to. Else, the UA can provide multipart/mixed while PSAP
> > expects multipart/alternative.
>
> It would be hard to imagine a use case where a UA generates
> multipart/alternative.  However, I don't mind adding text clarifying that
> multipart/mixed is expected.
>
> >
> >>  >  ISSUE 7
> >>  >
> >>  >  section 6 - "The IVS then attaches an updated MSD to a SIP
> >>  >     INFO request and sends it within the dialog." - what is meant by
> >>  > "attaching MSD to SIP INFO request"?
> >>
> >>  I think that's made abundantly clear in the multiple earlier
> >> instances in the
> >>  same section that say "as a MIME body part".
> >
> >  I do not really know what "attach body to SIP request"  means.
> > Likely, other readers will not know it either.
> >
> >  A reference to a section defining how to "attach body to SIP
> > request" would help.
>
> It's the same section, just a little bit before.
>
> >
> >
> >>  >  ISSUE 9
> >>  >
> >>  >  section 9 - what is "SIP status message"?
> >>
> >>  I do not see "SIP status message" anywhere in the document.
> >
> >  It was in -015 section 9 but it looks like it was already resolved in
> -18.
> >
> >
> >>  >  ISSUE 10
> >>  >
> >>  >  "
> >>  >  For
> >>  >     example, if a PSAP is unable to accept an eCall (e.g., due to
> >>  >     overload or too many calls from the same location), it can
> reject the
> >>  >     INVITE.  Since a metadata/control object is also included in the
> SIP
> >>  >     response that rejects the call, the IVS knows if the PSAP
> received
> >>  >     the MSD, and can inform the vehicle occupants that the PSAP
> >>  >     successfully received the vehicle location and information but
> can't
> >>  >     talk to the occupants at that time." - this prevents persons in
> >>  > the car from getting emergency service of the PSAP using other means
> >>  > (e.g. using circuit switched network). Possibility for DOS attack.
> >>
> >>  If the PSAP is overloaded (e.g., there is a very large multi-vehicle
> >>  incident, or another large-scale emergency incident), then there are
> likely
> >>  to be multiple simultaneous eCall attempts.  The document does not
> >> in any way
> >>  dictate or mandate PSAP response.  PSAPs are free to respond as
> >> they choose.
> >>  E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can
> reject an
> >>  eCall and include an ack with "received=false", a PSAP can reject an
> eCall
> >>  and include an ack with "received=true".  Doing the latter
> >> indicates that the
> >>  PSAP has received the MSD and hence is aware of the incident.
> >
> >  How can the UA be sure that such response was sent by PSAP and not
> > by an attacker, located somewhere between UA and PSAP?
> >
> >  Any SIP entity which happens to be in the path of the emergency
> > call INVITE request can generate a 600  (Busy Everywhere), 486
> > (Busy Here), and 603 (Decline) response and populate it with a
> > particular body.
> >
> >  It is at least a security risk and it needs to be documented.
>
> OK, I'll add some text.
>
> >
> >>  >  ISSUE 11
> >>  >
> >>  >  "The body for an emergencyCallData.eCall.MSD info package is a
> >>  > multipart body." - which multipart MIME type is meant?
> >>  > multipart/mixed or multipart/alternative or ....
> >>
> >>  We do not need to get into that level of detail in this text.
> >
> >  IMO, we need to. Else, the UA can provide multipart/mixed while
> > PSAP expects multipart/alternative.
>
> Same answer as above.
>
> >
> >>  >  ISSUE 14
> >>  >
> >>  >  "while others can be
> >>  >     expected to carry an occasional request" - meaning of
> "occasional"
> >>  > can be whatever, it depends on perspective of the user
> >>  > - once per milisecond, once per second, once per minute, once per
> hour
> >>  > or once per day?
> >>
> >>  Other text makes it clear that a request for an updated MSD is
> >> generally sent
> >>  upon manual request of a PSAP call taker who suspects vehicle
> >> state may have changed.
> >
> >  A statement that the request is expected to be triggered by manual
> > action of the PSAP call taker is good, so I suggest to add it to
> > this section too as expert reviewer will read it.
>
> OK, I'll add text.
>
> >
> >>  >
> >>  >  ISSUE 18
> >>  >
> >>  >  Accept in Figure 10 is not correct - INFO response is not expected
> >>  > to contain body.
> >>
> >>  Fixed, thanks for catching this.
> >
> >  in -18, I can still see Accept with multipart/mixed in the INFO
> > request in Figure 10.
>
> I don't see it.  Here is Figure 10:
>
>      INFO sip:[e-mail] SIP/2.0
>      To: <sip:[e-mail]>;tag=9fxced76sl
>      From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0
>      Call-ID: [e-mail]
>      Call-Info: <cid:[e-mail]>;
>                 purpose=emergencyCallData.control
>      CSeq: 41862 INFO
>      Info-Package: emergencyCallData.eCall.MSD
>      Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
>             SUBSCRIBE, NOTIFY, UPDATE
>      Content-Type: multipart/mixed; boundary=boundaryZZZ
>      Content-Dispositio: Info-Package
>      Content-Length: ...
>
>      --boundaryZZZ
>      Content-Disposition: by-reference
>      Content-Type: application/emergencyCallData.control+xml
>      Content-ID: <[e-mail]>
>
>      <?xml version="1.0" encoding="UTF-8"?>
>      <emergencyCallData.control
>          xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
>      <request action="send-data" datatype="eCall.MSD"/>
>
>      </emergencyCallData.control>
>       --boundaryZZZ--
>
>                        Figure 10: INFO requesting MSD
>
>
>
>
> >
> >  IMO, this is wrong as we do NOT expect a body in INFO response.
> > Yes, there will be a body in subsequent INFO request sent in
> > opposite direction, but that's not impacted by Accept in first INFO
> > request.
> >
> >>  >
> >>  >  ISSUE 20
> >>  >
> >>  >  examples contain a value of schemaLocation parameter which is not
> >>  > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation
> >>  > stating "The schemaLocation attribute value consists of one or more
> >>  > pairs of URI references, separated by white space. "
> >>  >
> >>  >             xsi:schemaLocation=
> >>  >                 "urn:ietf:params:xml:ns:EmergencyCallData:control"
> >>
> >>  Fixed.
> >
> >  I can see in -18, that you chose to remove the information about
> > schema location from the XML examples.
> >  That's OK with me.
> >
> >  However, then you can also remove the following as it is not needed any
> more
> >
> >       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> I've asked Hannes to verify the XML schema and examples as part of
> IETF Last Call.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Question Authority.  They usually know where the bathroom is.
>                                               --MTV's 'Daria'
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>