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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 18 October 2016 13:38 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 3C0F8129A5D for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 06:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Qdg87FM_8-dS for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 06:38:44 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFC41294C6 for <ecrit@ietf.org>; Tue, 18 Oct 2016 06:38:43 -0700 (PDT)
X-AuditID: c1b4fb2d-5b107980000009f7-a9-580625e1e05f
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 0F.A7.02551.1E526085; Tue, 18 Oct 2016 15:38:41 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 15:38:40 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Randall Gellens <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
Thread-Index: AQHSKM9pnC2aMUPzqUuYRM5JMx1G9qCt+/AAgABO/YA=
Date: Tue, 18 Oct 2016 13:38:40 +0000
Message-ID: <D42C016C.11565%christer.holmberg@ericsson.com>
References: <p06240605d42aaac123bb@[99.111.97.136]> <AM5PR0701MB2468193301B56352CE85005DE5D30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2468193301B56352CE85005DE5D30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1F93B6054FB18545BD82875BE36455E5@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7iO5DVbYIg1XPrSwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4MqYe/AZW8FEl4p1934wNzD2m3YxcnJICJhI /P/0ir2LkYtDSGA9o8Ty5ocsEM5iRomDO9YDZTg42AQsJLr/aYM0iAjUSezYtYcVxBYWsJOY 9XMyC0TcXuLr95fMELaVRF/rJrA4i4CqRMfqT8wgY3gFrCXO90ZBjO8CGv+7nw2khlMgUWJR x0ewmYwCYhLfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgswUFdCTWHM/DCKsKPHx 1T5GiFY9iRtTp7BB2NYSJ04+YYawtSWWLXwNZvMKCEqcnPmEZQKj2Cwk22YhaZ+FpH0WkvZZ SNoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMqoNbfuvuYFz92vEQowAHoxIPb8JN lggh1sSy4srcQ4wSHMxKIrxXVdgihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliS mp2aWpBaBJNl4uCUamDU0FZbsOcaV7nnx59Lz08PU/393k7R9dBME87inmopreydjMu1Lvt7 xUryr0ib7276J4fn6hk5nn3xS3s5W5fOill74Wh664YD6WpRUpUr/Sfw5SzJcHLL7GNjv9IZ 9Pxm+Xm+t3wLDqaL3r4e8kGi79eN/G8tLE6XeUp6blbPXfNvpcjklXxKLMUZiYZazEXFiQAr qQutpgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/LPcUkFrBoRmq18ueUAPsqDZcrsQ>
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 13:38:46 -0000

Hi,

Regarding indicating the type of multipart (mixed, alternative etc), I
agree with Ivo. 

Unfortunately RFC 6086 doesn¹t normatively define the type either (in the
examples multipart/mixed is used, though), why I think it¹s even more
important to do it in draft-ecall.

Regards,

Christer


On 18/10/16 15:02, "Ecrit on behalf of Ivo Sedlacek"
<ecrit-bounces@ietf.org on behalf of ivo.sedlacek@ericsson.com> 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.
>
>> >  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
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit