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

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

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
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit