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

[Brian Rosen <[e-mail]>]

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




On Jul 12, 2011, at 5:52 AM, Hannes Tschofenig wrote:

> Hi Brian, 
> 
> On Jul 11, 2011, at 7:40 PM, Brian Rosen wrote:
> 
>> 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.
> 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.  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.
> 
> 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 have is data.
> 
> 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:[e-mail]</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 really should be used for a one way alert.  So, we put the CAP message in a SIP MESSAGE transaction.
> 
> Ok. Fine with me.
> 
> Ciao
> Hannes
> 
>> 
>> Brian
>> 
>> On Jul 8, 2011, at 7:15 AM, Hannes Tschofenig wrote:
>> 
>>> 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
>>> 
>>> On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote:
>>> 
>>>> Hi Bernard, 
>>>> 
>>>> On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote:
>>>> 
>>>>> 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. 
>>>> 
>>>> 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.
>>>> 
>>>>> 
>>>>> 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. 
>>>> 
>>>> 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. 
>>>> 
>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> 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. 
>>>> 
>>>>> 
>>>>> 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 put text into the draft already about the case where the two are different. 
>>>> 
>>>>> 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.
>>>>> 
>>>> 
>>>> I proposed text already that follows this type of structure - although not with sub-section headings. 
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 
>>> 
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>