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

[Christer Holmberg <[e-mail]>]

Hi,

There haven’t been any consensus calls on the issues currently discussed, and I don’t think there need to be any: it’s mostly about sorting out and clarifying details. I don’t think there are any major open issues.

Regards,

Christer

From: Az Mankin [mailto:[e-mail]]
Sent: 18 October 2016 20:53
To: Christer Holmberg <[e-mail]>
Cc: Randall Gellens <[e-mail]>; Ivo Sedlacek <[e-mail]>; [e-mail]
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

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]<mailto:[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]<mailto:[e-mail]> SIP/2.0
     To: <sip:[e-mail]<mailto:[e-mail]>>;tag=9fxced76sl
     From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0
     Call-ID: [e-mail]<mailto:[e-mail]>
     Call-Info: <cid:[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ecrit