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

Randall Gellens <rg+ietf@randy.pensive.org> Tue, 18 October 2016 17:37 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD1B129785 for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 10:37:05 -0700 (PDT)
X-Quarantine-ID: <VTzJUgpCvlD1>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTzJUgpCvlD1 for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 10:37:03 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0566D12973E for <ecrit@ietf.org>; Tue, 18 Oct 2016 10:36:25 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 18 Oct 2016 10:36:24 -0700
Mime-Version: 1.0
Message-Id: <p06240602d42c0df8652d@[99.111.97.136]>
In-Reply-To: <AM5PR0701MB2468799333E3B1B0BE8FD450E5D30@AM5PR0701MB2468.eurprd07.pro d.outlook.com>
References: <AM5PR0701MB2468EA4C8EBE8DE9D3ACE865E5DC0@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <AM5PR0701MB246808CF2BFEB41C0F8A150CE5DF0@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <AM5PR0701MB246837026B1D6B9DB49F941CE5D00@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <p06240605d42aaac123bb@[99.111.97.136]> <AM5PR0701MB2468193301B56352CE85005DE5D30@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <p06240600d42bf6a9ee81@[99.111.97.136]> <AM5PR0701MB2468799333E3B1B0BE8FD450E5D30@AM5PR0701MB2468.eurprd07.pro d.outlook.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 18 Oct 2016 10:36:22 -0700
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Az Mankin <azmankin@gmail.com>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Fwi8xyTqZHp7h77-K6KbONpu72Q>
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 17:37:05 -0000

Hi Ivo and Christer,

All comments have been addressed in -19.

Thank you.

At 4:43 PM +0000 10/18/16, Ivo Sedlacek wrote:

>  The comments were submitted as part of WGLC and I expect them to be 
> addressed during WGLC.
>
>  Kind regards
>
>  Ivo
>
>  -----Original Message-----
>  From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]
>  Sent: Wednesday, October 19, 2016 12:12 AM
>  To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>; Az Mankin 
> <azmankin@gmail.com>; ecrit@ietf.org
>  Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
>
>  Hi Ivo,
>
>  I think we can address any remaining comments as part of IETF Last Call.
>
>  --Randy
>
>  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:+13145551111@example.com SIP/2.0
>       To: <sip:+13145551111@example.com>;tag=9fxced76sl
>       From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0
>       Call-ID: 3848276298220188511@atlanta.example.com
>       Call-Info: <cid:3456789012@atlanta.example.com>;
>                  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: <3456789012@atlanta.example.com>
>
>       <?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'


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It's a good idea to obey all the rules when you're young just so you'll
have the strength to break them when you're old.           --Mark Twain