Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
Ivo Sedlacek <ivo.sedlacek@ericsson.com> Tue, 18 October 2016 16:43 UTC
Return-Path: <ivo.sedlacek@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 24B391296EA for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 09:43:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 WY5nN1su4xca for <ecrit@ietfa.amsl.com>; Tue, 18 Oct 2016 09:43:09 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3C9661296CF for <ecrit@ietf.org>; Tue, 18 Oct 2016 09:43:09 -0700 (PDT)
X-AuditID: c1b4fb30-b73ff70000000cb2-92-5806511a748c
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 0A.F4.03250.A1156085; Tue, 18 Oct 2016 18:43:07 +0200 (CEST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Oct 2016 18:43:06 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HFB7FKojRtrZJb1+2J6KNekO/3BlRjryAIPZ/7pfMU0=; b=HNjHXmTWHp/x3dxf4qUBgj65SUXD9dKQcnTzWzCSzEhuhI0mGenuG7a7s3O2SQ3iAORMy+51wQO6JL15mCPfAVzG6MvQA1CRZCzYRm4gR4T+bpOcjTO7DJrbdvO9cXk/fE5LRWBg9aQ1o5Hec5jB/GGTcm5kr5ou7RWdx3aalMc=
Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 18 Oct 2016 16:43:04 +0000
Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0679.006; Tue, 18 Oct 2016 16:43:04 +0000
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>, Az Mankin <azmankin@gmail.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15
Thread-Index: AQHSKM9jDqYN1mg4ykGyzqHQEQ3RAqCuYzmdgAAIVlA=
Date: Tue, 18 Oct 2016 16:43:04 +0000
Message-ID: <AM5PR0701MB2468799333E3B1B0BE8FD450E5D30@AM5PR0701MB2468.eurprd07.prod.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]>
In-Reply-To: <p06240600d42bf6a9ee81@[99.111.97.136]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com;
x-originating-ip: [220.173.138.14]
x-ms-office365-filtering-correlation-id: 2c5678e7-1032-43e3-a627-08d3f775d52b
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2467; 7:gXR/fuvu38KNQTYWJKKeO+Z2vtaaR/WFkfzwtWvYxScNWP0GD5sLrdSJKh0nrbUE3T9ABr7LMmkThu9yjPbO/I/PCto1A6PahF4AcEMqM1E5o/2MbhmdO+YcmjgcuhL6ZOZN+5+HgrfAOXjLOZ1AkrsNPNgmpZ0/CRgzZYZOtcUHsljgEpeoE2oL3QeFB1MMkrON6uHnAJgHb+IpLkoJsiRmuJWKKewXGBH7qDVUZXdHQH57hFQhTLByzAWTvkFJ+vm5pZgFHOXViEtNmH7gePWCCPaCQ/3ovH7Xv+fzIW0CsridRrOieSF64A2HWeuysfLIG60q6tRNDU+BacWa1w4Twf4/I1sSKnvyZb7qtN8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2467;
x-microsoft-antispam-prvs: <AM5PR0701MB2467353F655FED218AAFAACBE5D30@AM5PR0701MB2467.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM5PR0701MB2467; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2467;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(377454003)(51444003)(199003)(189002)(7696004)(2950100002)(122556002)(5002640100001)(10400500002)(5660300001)(66066001)(5001770100001)(97736004)(54356999)(101416001)(189998001)(76176999)(50986999)(33656002)(2501003)(5890100001)(2906002)(107886002)(9686002)(86362001)(2900100001)(8936002)(586003)(87936001)(106356001)(305945005)(74316002)(7846002)(93886004)(76576001)(11100500001)(105586002)(106116001)(6116002)(102836003)(230783001)(8676002)(77096005)(3660700001)(3846002)(81166006)(81156014)(15975445007)(68736007)(92566002)(7736002)(19580395003)(19580405001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2467; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 16:43:04.7572 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2467
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOd9l+1wOTkvzxRnEyMS8ZGImUrb+W4Sm0UWk0JlfaumUfVPS qOxGOcmKJeTosmwliVJOxUxNXUpamqEhGUqkk2leEg28JJnbWdB/v/M+z/ue8z4cjpYVs95c ukbHazXqDIVIwpTG14cHyeNE8SEf5vwinpY0UBGXysbYiAW7HilpVYNxWKwym5coVd3QKBNL J0h2p/AZ6bm8dntUkiSt+XK/KPvtkbO9pmWqAI0p9ciNAxwGjSUTlB5JOBl+gWB6skJMDp0I 7tXYaIeLwTdp6GmKIsIDCuYfXnW1dCOomxyhHC4RDoY7te2sHnGcB9bBR8NhR3kD3guPLD8Y B3tgJYzp28XEEgnvFmRkvi+sGJeRg6U4CTqnBhAZ30bD67pW1iG4rT3V8LPaeRXCG2HhfaWT aewFX22PKLIOBnNTL03YEyZG/7DEfxxWi+ZZUlfAYk2piHA0dE8sMoTLaJhewoRV8GWxzzUz C1rKBl2eA1BktDkTAtyEYGRwGBHBB8p/3WKIYBLBSLPN2S3DPJRXXUMkCW8Y/lzoYh8YH2pm byN/439LEA4EU+OciHAAPHs8SRudyayHrlIbY0JMBfIUeCE5MzU0NJjXpp8UhCxNsIbXWdDa L2mr/R3yCk3Y91kR5pDCXZo0yMTLWHWukJdpRcDRCg9p8kFRvEyaos7L57VZidqcDF6wIjnH KLyk4c+/HZPhVLWOP8Pz2bz2n0pxbt4FyKeorVg+46UMbf00HhidP3nK9zz28d50Ijj2bswM NRt0YzXGlOfXbbnQcrpyS5zJcH326HipPd0gCO5X3qQmn8vpn3q581CPfyEfNrbypL5LHKO5 n2itChil9kTur+Y6JJtnxB1b5doG6y6rub5R6Gu1R+Gui5Z1fQUJA/zQdwUjpKl3bKO1gvov 51qDcSEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/ryXluFQHr7Vj37Cx-2D2mihQnRw>
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 16:43:12 -0000
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'
- [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