Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18

Brian Rosen <br@brianrosen.net> Thu, 29 August 2019 21:47 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5795C1200CE for <secdir@ietfa.amsl.com>; Thu, 29 Aug 2019 14:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 Fk0R_hmoqt73 for <secdir@ietfa.amsl.com>; Thu, 29 Aug 2019 14:47:49 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1AA120824 for <secdir@ietf.org>; Thu, 29 Aug 2019 14:47:49 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id d23so4417863qko.3 for <secdir@ietf.org>; Thu, 29 Aug 2019 14:47:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=GLFPvKfXicijOD6QoKr4vUOukryMV7rZ0nWi4wQIZE123TC22sb8bLj86sovlB0TF8 eTYzE/JLX1jF2Df45w/0/OjmnlXQZrQPIgvui0UpVNdJdnNrFvEM9LsQWU7NiudMPhE2 lAu1I/8Nd8cN7d6oBwtB2iPge5Qk2GCoUoxBUO2jrH7PHztcnG05noqIZMBF/SKY/xtS yT+MOC/lKZ0j9/vs0Az355eJajxcWsz3kDoCchNyICCHSMKI8qjhRtFn3Igp2JWeTJJO nn6M7evdKO9r0onKQkWZIRP3bP149YBJA7VNI6E3jF29SJdSySJ+N1USzwIFGlerCp4T WZrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=odg6dpKij/LmHrS2Ds0OllMn7Rdvh+ENHikA91oO+zw=; b=UzC66rDFW1ZPgM5utiM6o+wYOIQcWh8fF/qY2j2lIiAf4wre6Ep78lSXknz2nNfhMX FuzQTOR0RY8ufq70KOypYY/sC7WWyx4+n6JRpmhNgX3MfsU1gI9ZduSaJ/KjjQ9SNDb7 O8JeLUGrl2n6zsSPPIwt6EkyQA9iPTSTfFCAAQzTDZgAzDDFjBUZuR87jiO1iLC+Ir9y B1UY/lgLkh3jYN3XInvYiwLVPqj9QreAuJiehOvpzpiFR3i+5m1awZOZ1UunlTUyMyNr XTwRJEgn56fYdsYPr8kTWeGh6nWXvGkhGN/z1LKPjFiPJQE/h3EFQNagzPeHMKDVkccj df+g==
X-Gm-Message-State: APjAAAUKHJXzrCtLCsYvdUjtcGeMs4P6BsnSiYGmG761wp/0eMxJ0ioX /UZP2/08In7VFNHejxm+/UeScg==
X-Google-Smtp-Source: APXvYqx6RkdYwpPngDSyxaNuClliKzu+fPVzNFft/+uFQHx951tNpcpXw+5Tzhah6lZ8skdVORo+aA==
X-Received: by 2002:a37:4a0b:: with SMTP id x11mr12078508qka.395.1567115268455; Thu, 29 Aug 2019 14:47:48 -0700 (PDT)
Received: from brians-mbp-2388.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id r189sm1875773qkc.60.2019.08.29.14.47.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 14:47:47 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <1D728931-DCCE-4A87-A247-A4A7FE1D8BE7@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93D6D405-21E2-400A-84BF-6D9B1923FE1F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 29 Aug 2019 17:47:45 -0400
In-Reply-To: <MWHPR04MB036724650A0D208BE4D22D58DFA20@MWHPR04MB0367.namprd04.prod.outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ecrit-data-only-ea.all@ietf.org" <draft-ietf-ecrit-data-only-ea.all@ietf.org>
To: Charlie Kaufman <charliekaufman@outlook.com>
References: <MWHPR04MB0367DA96CF172D996CDDA622DFA70@MWHPR04MB0367.namprd04.prod.outlook.com> <DAD38B77-66B6-40CD-9200-DDA7632EED94@brianrosen.net> <MWHPR04MB036724650A0D208BE4D22D58DFA20@MWHPR04MB0367.namprd04.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ObaA2a8JwERlGHLET435DoERChU>
Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Aug 2019 21:47:55 -0000

It’s new functionality.  RFC6881 defines an interactive emergency call that uses SIP INVITE.  It does not have a CAP message.  This document defines a non-interactive (in the real time media sense) call that uses SIP MESSAGE and includes the CAP message.

To get CAP into any SIP transaction, you put it in.a ‘body’ which is MIME encoded.  So the layering is:
SIP MESSAGE
	bodypart MIME
		CAP

Brian

> On Aug 29, 2019, at 5:17 PM, Charlie Kaufman <charliekaufman@outlook.com>; wrote:
> 
> My confusion had to do with whether this is adding new functionality or whether this is a profiling of existing functionality to enable a lightweight interaction. For example, is it possible to send a CAP message within a SIP transaction when there is going to follow interactive two way media in the existing protocol? If so, this could have been done with the previous protocol just by ending after the first exchange. If not, this is something that couldn't have been done before and this is new functionality (and I would wonder why the old protocol did not allow this).
> 
> My confusion might be based on my lack of understanding of the layering of CAP, SIP, and MIME, and it could be that anyone with a legitimate reason to read this document would not be confused.
> 
> --Charlie
> 
> p.s. Apologies for the formatting. I'm using Outlook's web interface, which tends to be overly clever and mess things up.
> 
> Sent from Outlook <http://aka.ms/weboutlook>
> 
> From: Brian Rosen <br@brianrosen.net>;
> Sent: Monday, August 26, 2019 1:34 PM
> To: Charlie Kaufman <charliekaufman@outlook.com>;
> Cc: secdir@ietf.org <secdir@ietf.org>;; iesg@ietf.org <iesg@ietf.org>;; draft-ietf-ecrit-data-only-ea.all@ietf.org <draft-ietf-ecrit-data-only-ea.all@ietf.org>;
> Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18
>  
> Hi Charlie
> 
> Thanks for the review, I appreciate it.
> 
> The introduction section has this text
>    Data-only emergency calls are similar to regular emergency calls in
>    the sense that they require the emergency indications, emergency call
>    routing functionality and may even have the same location
>    requirements.  However, the communication interaction will not lead
>    to the exchange of interactive media, that is, Real-Time Protocol
>    packets, such as voice, video data or real-time text.
> 
>    ...
> 
>    This document describes a method of including a CAP message in a SIP
>    transaction by defining it as a block of "additional data" as defined
>    in [RFC7852 <https://tools.ietf.org/html/rfc7852>].  The CAP message is included either by value (the CAP
>    message is in the body of the message, using a CID) or by reference
>    (a URI is included in the message, which when dereferenced returns
>    the CAP message).  The additional data mechanism is also used to send
>    alert specific data beyond that available in the CAP message.  This
>    document also describes how a SIP MESSAGE [RFC3428 <https://tools.ietf.org/html/rfc3428>] transaction can
>    be used to send a data-only call.
> 
> 
> This says that this document describes how to send an emergency call when there is not two way interactive media (voice, video and/or text), and it says that the way you do that is to send a SIP MESSAGE, with a CAP message pointed to by a Call-Info header.
> 
> That text seems very clear to me, and yet you didn’t read what we hoped into what we wrote.  I would really like to fix this, but I’m at a loss to understand what I need to do.
> 
> I’ll improve the acronym stuff.
> 
> 
>> On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com <mailto:charliekaufman@outlook.com>> wrote:
>> 
>> 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 defines a new MIME type: 'application/EmergencyCallData.cap+xml' for use primarily by sensors to send alert messages to emergency services providers. It also defines a new Emergency Call Data Type: 'cap' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already noted for the protocols carrying these messages.
>> 
>> I do have some editorial suggestions:
>> 
>> There is a lot of context that the authors assumed any reader would have that could have been stated in the introduction. I believe from context that the purpose of this new MIME type is to support simple (IoT) sensors that don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.
>> 
>> I got the impression that the functionality provided could have been done with existing protocols by sending the CAP message over a SIP session, but that doing so would place an unnecessary burden on simple (IoT) sensors, and that this protocol would be easier for such sensors to implement for the limited cases such sensors need to deal with. If that's true, it should be stated. If not, the purpose of this protocol should be more clearly stated.
>> 
>> These acronyms were used but never defined:
>> 
>> SIP
>> CID
>> LoST
>> 
>> These acronyms were expanded, but not in an easy to find place:
>> 
>> Common Alerting Protocol (CAP)
>> Public Safety Answering Points (PSAPs)
>> Emergency Services Routing Proxy (ESRP)
>> 
>> It would be nice to include them in the terminology section, ideally with a reference to the RFC where more information is available.
>> 
>> Typo:
>> 
>> p17 "security mechanism" -> "security mechanisms"
>> 
>>  --Charlie