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

[Ivo Sedlacek <[e-mail]>]

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.

> >  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.

---------
      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.

> >  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.


> >  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.

> >  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.

> >  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.

> >
> >  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.

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"

Kind regards

Ivo Sedlacek