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

[Charlie Kaufman <[e-mail]>]

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 <[e-mail]>
Sent: Monday, August 26, 2019 1:34 PM
To: Charlie Kaufman <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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