Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jul 2011 16:49:24 -0700

Hannes said:

The question is also whether we need to restrict the way a CAP payload is sent to a recipient. 
One could argue that it does not really matter whether it is an INVITE, a MESSAGE, or a PUBLISH. 
Which one is best depends on a specific environment. 

But you seem to be arguing that we should rather stick with the INVITE instead of using MESSAGE. 
This would at least allow us to get the message understood by every SIP device. [BA] I have no problem with including CAP in MESSAGE.  My major concern was how to ensure interoperability and potential
problems that could delay emergency calls. 

This is just an example. Using TCP indeed makes sense for XML-based payloads. 
I don't think we want to mandate that TCP is mandatory-to-use. [BA] I agree that we don't want to mandate use.  But we are talking about emergency calls, so making a recommendation on how to avoid problems is probably a good idea. 

I assume that the device that issues the alert is actually an IP-based device. 
For me the story begins with the first IP device. 
 
[BA] My problem with signatures is in emergency contexts is the cost and value of validating them.    In ATOCA there may
be a model for this (e.g. government signs the CAP), but in a device scenario, it's not easy to figure out how a PSAP would
validate the signature or what value it would have. 

With SIP Identity the identity header is either added by the end point (unlikely) or by the outbound proxy. 
If it is added by the outbound proxy then there has to be TLS between the end point and the outbound proxy. 
This would provide proper protection of the message exchange and would fulfill our purpose here. Wouldn't you say so? [BA] TLS is fine with me -- but it solves a different problem than RFC 4474.

True. There is the SIP identity of the sender, the field in the CAP message (sender field), and then there is cryptographic material in case of a signature that will have some identity information associated with it. 
Currently, the draft says that we should set the sender field of the CAP message to the value of the sender of the SIP message. Useful to set to two equal?[BA] That is useful if the CAP sender and SIP sender are actually the same.  If not, then the CAP sender field should reflect who composed the CAP. 

I am OK with not focusing on security threats as the document currently does, but instead focus on the solutions. 
Using the terminology from the ATOCA requirements document maybe it is better to talk about 

1) Verification of the alert originator (this is the SIP stuff) 
2) Verification of the alert author (this is the alert stuff)
3) Integrity of alerts in transit (the TLS)

OK for you? 

[BA] Yes, that is a better approach.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jul 2011 10:50:14 +0300

Hi Bernard, 

On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote:

> This would at least allow us to get the message understood by every SIP device. 

> [BA] I have no problem with including CAP in MESSAGE.  My major concern was how to ensure interoperability and potential

Your suggestion to use INVITE seemed to be interesting but after further thinking about it I am not sure whether the perceived level of interoperability is worth sticking only with an INVITE. If the recipient does not understand the CAP payload (and only the INVITE itself) then there is still no interoperability. 

As such, I believe I have to put text in there regarding error messages and the core SIP spec already provides them, namely 
* 501 Not Implemented, and 
* 415 Unsupported Media Type

I am still thinking whether we should allow the CAP payload to be used in an  INVITE, a MESSAGE, an a PUBLISH.

> I don't think we want to mandate that TCP is mandatory-to-use. 
> 
> [BA] I agree that we don't want to mandate use.  But we are talking about emergency calls, so making a recommendation on how to avoid problems is probably a good idea. 
> 

> validate the signature or what value it would have. 

I agree with you that most deployments will in their judgements about the security threats conclude that they do not need to additionally sign the CAP message and instead rely on the SIP security mechanisms. That's my assumption. Still, the security consideration section lays out the options. 

> This would provide proper protection of the message exchange and would fulfill our purpose here. Wouldn't you say so? 
> 
> [BA] TLS is fine with me -- but it solves a different problem than RFC 4474.

In the typical use case of SIP Identity (at least as envisioned in the specification) the identity assertion is added by the Authentication service (e.g. the outbound proxy) and there still has to be security provided from the end host to that Authentication Service. This may likely come in form of TLS since otherwise the identity assurance is of little value if the adversary is sitting somewhere along that path. 
 
> Currently, the draft says that we should set the sender field of the CAP message to the value of the sender of the SIP message. Useful to set to two equal?
> 
> [BA] That is useful if the CAP sender and SIP sender are actually the same.  If not, then the CAP sender field should reflect who composed the CAP. 
> 

I put text into the draft already about the case where the two are different. 

> [BA] Yes, that is a better approach.

I proposed text already that follows this type of structure - although not with sub-section headings. 

Ciao
Hannes

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jul 2011 14:15:49 +0300

I have updated the draft to reflect our discussion. Please find the most recent version here:
http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-ietf-ecrit-data-only-ea-02.txt

I now changed Section 4.1 that talks about the CAP transport: 

-----

4.1.  CAP Transport

   Since alerts structured via CAP require a "push" medium.  The
   following SIP requests MAY carry the CAP payload defined in this
   document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], INFO
   [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903].  The MIME type is
   set to 'application/cap+xml'.

   If the server does not support the functionality required to fulfill
   the request then a 501 Not Implemented MUST be returned by RFC 3261
   [RFC3261].  This is the appropriate response when a UAS does not
   recognize the request method and is not capable of supporting it for
   any user.

   The 415 Unsupported Media Type error MUST be returned by RFC 3261
   [RFC3261] if the server is refusing to service the request because
   the message body of the request is in a format not supported by the
   server for the requested method.  The server MUST return a list of
   acceptable formats using the Accept, Accept-Encoding, or Accept-
   Language header field, depending on the specific problem with the
   content.

-----

Ciao
Hannes

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Jul 2011 08:25:05 -0700

Thanks. You might mention the Allow: header, as well as potential advice for avoiding errors (e.g. checking Allow: or Accept: headers, sending OPTIONS, etc.)

> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01
> From: [email-masked]
> Date: Fri, 8 Jul 2011 14:15:49 +0300
> CC: [email-masked]; [email-masked]
> To: [email-masked]
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 10 Jul 2011 22:49:07 +0300

I put additional text into the document regarding error handling. I got inspired by the SIP location conveyance document. 
Let's see whether there is still room for improvement. Here is the updated draft:
http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-ietf-ecrit-data-only-ea-02.txt

---

From: Brian Rosen <[email-masked]>
Date: Mon, 11 Jul 2011 12:40:17 -0400

I am sorry I was not able to participate in this discussion. I think it is heading in the wrong direction.

CAP is a wrapper for data related to an alert.  It's a very common wrapper, but it's just a wrapper.  With respect to a citizen to authority alert, it doesn't provide enough information by itself, and it doesn't provide the kind of location based routing mechanisms we need for these kinds of alerts.

The payload of the alert, that provides the information we need, should be the "Additional Call Data" structure we are working on in ecrit.

We need a SIP mechanism to allow the -phonebcp routing we need for a DATA ONLY alert.  An alert of this kind has an important characteristic uncommon with media sessions - there is no media session.  MESSAGE has the appropriate semantics when used in the "pager" mode.  It's a one time, no session, SIP transaction with the interesting part in the body of the message.

If you have a media session, and what you want to do is send sensor data in the INVITE, the Additional Call Data mechanism does that.  This mechanism is used only when you have no media, all you have is data.

What this really means is that we could, if we wanted to, just put a Call Info header on a MESSAGE transaction and treat it like a call, but most of the sources we have talked to believed that CAP really should be used for a one way alert.  So, we put the CAP message in a SIP MESSAGE transaction.

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Jul 2011 12:52:07 +0300

Hi Brian, 

> CAP is a wrapper for data related to an alert.  It's a very common wrapper, but it's just a wrapper.  With respect to a citizen to authority alert, it doesn't provide enough information by itself,…
Correct. For this reason the document assumes that location in the form of a PIDF-LO is attached. I put text in there versions ago. 

> The payload of the alert, that provides the information we need, should be the "Additional Call Data" structure we are working on in ecrit.

True. There may be additional data there as well. I could make this explicit in the draft. 

> We need a SIP mechanism to allow the -phonebcp routing we need for a DATA ONLY alert.  An alert of this kind has an important characteristic uncommon with media sessions - there is no media session…

In essence you are arguing that we should only stick with the MESSAGE rather than allowing the CAP payload to be carried also in the INVITE [RFC3261], UPDATE [RFC3311], INFO [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903] messages.

> If you have a media session, and what you want to do is send sensor data in the INVITE, the Additional Call Data mechanism does that.  This mechanism is used only when you have no media, all you ha…

Well. The additional call data as it is written now does not provide the same amount of information as the CAP message. For example, if you look at the example from http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-02#section-6

   <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
     <identifier>S-1</identifier>
     <sender>sip:[email-masked]</sender>
     <sent>2008-11-19T14:57:00-07:00</sent>
     <status>Actual</status>
     <msgType>Alert</msgType>
     <scope>Private</scope>
     <incidents>abc1234</incidents>
     <info>
         <category>Security</category>
         <event>BURGLARY</event>
         <urgency>Expected</urgency>
         <certainty>Likely</certainty>
         <severity>Moderate</severity>
         <senderName>SENSOR 1</senderName>
         <parameter>
           <valueName>SENSOR-DATA-NAMESPACE1</valueName>
           <value>123</value>
         </parameter>
         <parameter>
           <valueName>SENSOR-DATA-NAMESPACE2</valueName>
           <value>TRUE</value>
         </parameter>
     </info>
    </alert>

The <parameter> block is not standardized so there is no difference to the additional data either. Then, there are a few elements like <msgType>, <scope>, <incidents>, <category>, <event>, <urgency>, <severity> etc. that do not have an equivalent in the additional data structure at the moment. Of course one could question the usefulness of these fields (which I sometimes do). 

Additionally, I wonder why we actually have to stick with an XML encoding of the additional data (and with the CAP payload as well). It is just verbose for no good reason. Why don't we use JSON? Just thinking loud...
The JSON encoding would also allow us to have an implementable end-to-end security solution (as a side remark). 

> What this really means is that we could, if we wanted to, just put a Call Info header on a MESSAGE transaction and treat it like a call, but most of the sources we have talked to believed that CAP…

Ok. Fine with me.

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Tue, 12 Jul 2011 09:43:58 -0400

The problem with CAP is that none of the field content is standardized.  It's useful to a human, less so to an automaton without agreement between senders and recipients on how to interpret the fields.

The "parameter" thing is particularly difficult that way.

About the only thing that CAP has that we would may want to see in the sensor data section of Additional data about a Call is the urgency/certainty/severity stuff.  However, it is not so clear that when you have a real call (an INVITE) that such information is actually so useful.

I could imagine allowing a CAP block in AdditionalData, but then we would really have a lot of tails and dogs and ...

Hmmmmm

Maybe not.

What if we DID allow a CAP block in Additional Data, and then made Data Only a MESSAGE with a Call Info/Additional Data?  

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Jul 2011 22:51:24 +0300

Hi Brian, 

> What if we DID allow a CAP block in Additional Data, and then made Data Only a MESSAGE with a Call Info/Additional Data?  

Let's look at the fields and see what we actually need. Below is the list of elements from the CAP specification. 

As you said in your earlier mail we cover the case where no session is established. 

"alert" Element and Sub-elements
----------------------------------------------

* <identifier>: The identifier of the alert message

[hannes] Having an identifier for the message would be useful but don't we have it already within SIP?

* <sender>: The identifier of the sender of the alert message

[hannes] This is also available via SIP unless we want to differentiate the entity that sends the SIP message vs. the entity that created the additional data. 

* <sent>: The time and date of the origination of the alert message

[hannes] This is also information available in SIP. 

* <status>: The code denoting the appropriate handling of the alert message
Code Values:
“Actual” - Actionable by all targeted recipients
“Exercise”- Actionable only by designated exercise participants; exercise identifier should appear in <note>
“System” - For messages that support alert network internal functions.
“Test” - Technical testing only, all recipients disregard
“Draft” – A preliminary template or draft, not actionable in its current form.

[hannes] We have a mechanism for testing emergency calls and alerts already. The others do not make sense in our context. 

* <msgType>: The code denoting the nature of the alert message
Code Values:
“Alert” - Initial information requiring attention by targeted recipients
“Update” - Updates and supercedes the earlier message(s) identified in <references>
“Cancel” - Cancels the earlier message(s) identified in <references>
“Ack” - Acknowledges receipt and acceptance of the message(s)) identified in <references>
“Error” indicates rejection of the message(s) identified in <references>; explanation SHOULD appear in <note>

[hannes] I am not sure whether we need a protocol mechanism since the alert msg itself. If a device sends data about an emergency then they can always send further alert messages with more info. 
But maybe this is useful where a human is somewhere in the loop. 

* <source>: The text identifying the source of the alert message
The particular source of this alert; e.g., an operator or a specific device.

[hannes] We have much more data as part of our additional data spec. 

* <scope>: The code denoting the intended distribution of the alert message
Code Values:
“Public” - For general dissemination to unrestricted audiences
“Restricted” - For dissemination only to users with a known operational requirement (see <restriction>, below)
“Private” - For dissemination only to specified addresses (see <address>, below)

[hannes] We have better ways in PIDF-LO to restrict the information via the rules. 

* <restriction>: The text describing the rule for limiting distribution of the restricted alert message

[hannes] We have better ways in PIDF-LO to restrict the information via the rules. 

* <addresses>: The group listing of intended recipients of the private alert message

[hannes] The SIP message already indicates the recipient. 

* <code>: The code denoting the special handling of the alert message

[hannes] not further defined and hence underspecified. 

* <note>: The text describing the purpose or significance of the alert message

[hannes] Any clear text field will be less useful for our purpose; who should type the text? 

* <references>: The group listing identifying earlier message(s) referenced by the alert message

[hannes] This is useful in context of the <msgType>

* <incidents>: The group listing naming the referent incident(s) of the alert message

[hannes] An incident identifier is useful although quite difficult to set for the end device.

"info" Element and Sub-elements
---------------------------------------------

* <language>: The code denoting the language of the info sub- element of the alert message

[hannes] This information refers to the text in the alert. Since we would not use clear text it would be less useful. 
A language tag for the user itself is useful but already in SIP. 

* <category>: The code denoting the category of the subject event of the alert message

(1) Code Values:
“Geo” - Geophysical (inc. landslide)
“Met” - Meteorological (inc. flood)
“Safety” - General emergency and public safety
“Security” - Law enforcement, military, homeland and local/private security
“Rescue” - Rescue and recovery
“Fire” - Fire suppression and rescue
“Health” - Medical and public health
“Env” - Pollution and other environmental
“Transport” - Public and private transportation
“Infra” - Utility, telecommunication, other non-transport infrastructure
“CBRNE” – Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack
“Other” - Other events

[hannes] This may be useful to provide additional information about the alert message, for example in a sensor context.  

* <event>: The text denoting the type of the subject event of the alert message

[hannes] Clear text field again. 

* <responseType>: The code denoting the type of action recommended for the target audience.
(1) Code Values:
“Shelter” – Take shelter in place or per <instruction>
“Evacuate” – Relocate as instructed in the <instruction>
“Prepare” – Make preparations per the <instruction>
“Execute” – Execute a pre-planned activity identified in <instruction>
“Monitor” – Attend to information sources as described in <instruction>
“Assess” – Evaluate the information in this message. (This value SHOULD NOT be used in public warning applications.)
“None” – No action recommended

[hannes] We don't need this field since the end device should not tell the PSAP what to do.

* <urgency>: The code denoting the urgency of the subject event of the alert message
(1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Immediate” - Responsive action SHOULD be taken immediately
“Expected” - Responsive action SHOULD be taken soon (within next hour)
“Future” - Responsive action SHOULD be taken in the near future
“Past” - Responsive action is no longer required
“Unknown” - Urgency not known

[hannes] I cannot come up with useful cases for our deployment context. 

* <severity>: The code denoting the severity of the subject event of the alert message
1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Extreme” - Extraordinary threat to life or property
“Severe” - Significant threat to life or property
“Moderate” - Possible threat to life or property
“Minor” - Minimal threat to life or property “Unknown” - Severity unknown

[hannes] Sounds nice but how are these values set automatically. 

* <certainty>: The code denoting the certainty of the subject event of the alert message
(1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Observed” – Determined to have occurred or to be ongoing.
“Likely” - Likely (p > ~50%)
“Possible” - Possible but not likely (p <= ~50%)
“Unlikely” - Not expected to occur (p ~ 0)
“Unknown” - Certainty unknown

[hannes] Same as above. 

* <audience>: The text describing the intended audience of the alert message

[hannes] Clear text. 

* <eventCode>: A system- specific code identifying the event type of the alert message

[hannes] underspecified. 

* <effective>: The effective time of the information of the alert message

* <onset>: The expected time of the beginning of the subject event of the alert message

* <expires>: The expiry time of the information of the alert message

[hannes] While these fields may be useful for early warning scenarios they are less obvious for 

* <senderName>: The text naming the originator of the alert message

[hannes] Clear text; we have information about the originator already in other places. 

* <headline>: The text headline of the alert message

[hannes] Not useful 

* <description>: The text describing the subject event of the alert message

[hannes] clear text again.

* <instruction>: The text describing the recommended action to be taken by recipients of the alert message

[hannes] Not useful for the UA-to-PSAP communication. 

* <web>: The identifier of the hyperlink associating additional information with the alert message

[hannes] also in the additional data 

* <contact>: The text describing the contact for follow-up and confirmation of the alert message

[hannes] information in the additional data. 

* <parameter>: A system- specific additional parameter associated with the alert message

[hannes] underspecified.
A small note: Those who want to provide some sensor specific information are better advised to make use of a document like "Media Type for Sensor Markup Language (SENML)" <draft-jennings-senml-06.txt>. The abstract of the document says: 

   This specification defines media types for representing simple sensor
   measurements in JSON.  A simple sensor, such as a temperature sensor,
   could use this media type in protocols such as HTTP to transport the
   values of a sensor.

"resource" Element and Sub-elements
----------------------------------------------------

[hannes] These fields are useful since we want to attach additional data to the data-only call but we do not need to stuff this into the CAP message. We could instead, as the additional data draft suggests, concatenate MIME types in a SIP msg. 

* <resourceDesc>: The text describing the type and content of the resource file. The human-readable text describing the content and kind, such as “map” or “photo,” of the resource file.

* <mimeType>: The identifier of the MIME content type and sub-type describing the resource file

* <size>: The integer indicating the size of the resource file

* <uri>: The identifier of the hyperlink for the resource file

* <derefUri>: The base-64 encoded data content of the resource file

* <digest>: The code representing the digital digest (“hash”) computed from the resource file

 "area" Element and Sub-elements
-----------------------------------------------

[hannes] We have already noticed earlier that the area elements do not meet our needs. We have a better mechanism with the PIDF-LO. 

* <areaDesc>: The text describing the affected area of the alert message

+ various location shapes: geocode, circle, polygon, altitude, ceiling 

Ciao
Hannes