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

[Brian Rosen <[e-mail]>]

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 <[e-mail]> 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 <[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