[secdir] SecDir review of draft-ietf-ecrit-car-crash-20

"Xialiang (Frank)" <frank.xialiang@huawei.com> Thu, 05 January 2017 03:46 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E27FF129526; Wed, 4 Jan 2017 19:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.32
X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gpYjyfVpslKW; Wed, 4 Jan 2017 19:46:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5792712988C; Wed, 4 Jan 2017 19:36:45 -0800 (PST)
Received: from (EHLO lhreml706-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYG59598; Thu, 05 Jan 2017 03:36:43 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com ( by lhreml706-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 5 Jan 2017 03:36:42 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([]) by SZXEMA417-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Thu, 5 Jan 2017 11:36:36 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-ecrit-car-crash.all@tools.ietf.org" <draft-ietf-ecrit-car-crash.all@tools.ietf.org>
Thread-Topic: [secdir] SecDir review of draft-ietf-ecrit-car-crash-20
Thread-Index: AdJnBOiI2uOclm7mRIGNPgfQq8n+vw==
Date: Thu, 05 Jan 2017 03:36:35 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12B099E25@SZXEMA502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12B099E25SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.586DBF4B.025D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0a215eadc670b448717f5bd47445141b
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pkXwWFoWPOy_bYSwxoJ2_idIHeE>
Subject: [secdir] SecDir review of draft-ietf-ecrit-car-crash-20
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 03:46:10 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles and conveying vehicle, sensor, and location data related to the crash or incident. Comparing to the ECRIT basic drafts [draft-ietf-ecrit-ecall] [RFC7852], this extension draft mostly reuses the same technical aspects of the basic drafts, with the introduction of some new things: a new set of vehicle (crash) data -- the Vehicle Emergency Data Set (VEDS), new attribute values to the metadata/control object, a new SIP INFO package of the VEDS MIME type, etc.

Since most technical aspects of this draft are unchanged from the basic drafts, all the security considerations in them apply for this draft well. The security consideration in [RFC5069] applies for this draft too. And these basic drafts already have very comprehensive and detailed considerations about privacy and security threats. Regarding the new introduced data and action values, this draft discusses the general security mechanisms to protect their CIA (e.g., certificate, encryption, ...) too. In Summary, I have no more security issues.

Summary: this document appears in reasonably good shape, and is written well. I think it is ready.