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

From: Charlie Kaufman <[email-masked]>
Date: Sat, 24 Aug 2019 19:53: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 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

---

From: Allison Mankin <[email-masked]>
Date: Sat, 24 Aug 2019 17:18:03 -0400

Thank you, Charlie. Authors, these are good suggestions!

On Sat, Aug 24, 2019 at 15:53 Charlie Kaufman <[email-masked]>
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.
>
> 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.
>
> It would be nice to include them in the terminology section, ideally with
> a reference to the RFC where more information is available.
>
> Typo:
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Aug 2019 16:34:49 -0400

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 <[email-masked]> wrote:
>

---

From: Charlie Kaufman <[email-masked]>
Date: Thu, 29 Aug 2019 21:17:10 +0000

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 <[email-masked]>
Sent: Monday, August 26, 2019 1:34 PM
To: Charlie Kaufman <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Secdir review of draft-ietf-ecrit-data-only-ea-18

Hi Charlie

   ...

   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.

On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <[email-masked]<mailto:[email-masked]>> wrote:

SIP
CID
LoST

Typo:

 --Charlie

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 Aug 2019 17:47:45 -0400

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 <[email-masked]> wrote:
> 
> Sent from Outlook <http://aka.ms/weboutlook>
> 
>> On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <[email-masked] <mailto:[email-masked]>> wrote:
>>