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
- [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Az Mankin
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens