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

[Christer Holmberg <[e-mail]>]

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