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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Apr 2011 10:20:54 +0800

The document is OK, modulo a few comments and nits:

Comments:

Section 3, Figure 2: Why does the sensor not perform the route selection itself?  If it doesn't, then this is little different to the first scenario, where proxy == aggregator.  This text is strange:

     [...] In case the LoST
   resolution is done at an emergency services routing proxy rather than
   at the entity issuing the alert since it may not know the address of
   the receiver.  

The reason given doesn't make any sense to me.  A proxy might perform routing because the sensor has limited capabilities, but that smells more like the scenario in Figure 1 instead.  Suggest reworking this example to either provide better justification, or to have the sensor do the LoST lookup.

Section 4.2: It's unclear what interoperability gain is achieved by constraining the CAP contents in this manner.  In particular, the scope seems like a strange constraint.  

Section 6.1: This seems to advocate the use of XML digital signatures.  That would be a bad idea.  Even CMS is better.  JOES would be better still.

Was "application/cap+xml" already taken?

Nits:

The example has a few errors:
-	It needs to be updated for the latest sipcore-location-conveyance version
-	The namespace prefix for the usage rules in the PIDF-LO are incorrect
-	The use of a mac: URI for identifying the device requires the definition of the mac: URI scheme.

What is the right case for scope?  I didn't check what the right answer is, but the example and the MUST use different case - one of them is probably wrong.

Who is "phrank"? [citation required]

Section 6.3: hanging sentence in the threat description: "In scenario [...]"

--Martin

On 2011-03-31 at 01:49:46, Marc Linsner wrote:
> This message starts the Working Group Last Call for draft "Common 
> Alerting Protocol (CAP) based Data-Only Emergency Alerts using
> 
> the Session Initiation Protocol (SIP)
> 
> "  (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).
> 
> This draft fulfills the WG milestone:
> 
> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only 
> Emergency Alerts using the Session Initiation Protocol (SIP)'
> 
> Please submit comments to the list by COB on Friday April 15, 2011.
> 
> 
> Thanks,
> 
> 
> -Marc Linsner-

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Apr 2011 11:48:38 +0800

On the mac URI scheme, we originally had this in the HELD identity extensions but it was suggested in no uncertain terms that this had buckley's chance of getting through. This led us to use an explicit XML entity, though I seem to recall somebody suggesting that we may have been able to do something with UUIDs.

Cheers
James 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomson, Martin
> Sent: Wednesday, 13 April 2011 12:21 PM
> To: Marc Linsner; [email-masked]
> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01
> 
> Section 3, Figure 2: Why does the sensor not perform the route selection
> itself?  If it doesn't, then this is little different to the first
> scenario, where proxy == aggregator.  This text is strange:
> 
>      [...] In case the LoST
> The reason given doesn't make any sense to me.  A proxy might perform
> routing because the sensor has limited capabilities, but that smells more
> like the scenario in Figure 1 instead.  Suggest reworking this example to
> either provide better justification, or to have the sensor do the LoST
> lookup.
> 
> Section 4.2: It's unclear what interoperability gain is achieved by
> constraining the CAP contents in this manner.  In particular, the scope
> seems like a strange constraint.
> 
> Section 6.1: This seems to advocate the use of XML digital signatures.
> That would be a bad idea.  Even CMS is better.  JOES would be better
> still.
> 
> What is the right case for scope?  I didn't check what the right answer
> is, but the example and the MUST use different case - one of them is
> probably wrong.
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Shida Schubert <[email-masked]>
Date: Wed, 20 Apr 2011 11:27:33 +0900

I reviewed the document and followings are some comments/questions. 

 In general, I am having a hard time understanding the intent of the 
draft. Is it defining a CAP document composition rule (4.2) for delivering 
the CAP message from citizen to authority only? OR is it defining a SIP 
usage to transport CAP message as well? If it's latter I think more should 
be said about how SIP entities should behave. I understand it is an 
experimental document but I think we need to clarify the scope of the 
document somewhat. 

 1. For scenario 1, I really don't think in reality a sensor will be 
     implementing a SIP stack simply to support the transport of 
     CAP message, it just seems like an overkill. I understand how 
     aggregator to PSAP should be SIP to re-use what is defined 
     in Phone-BCP and pre-exising infrastructure. May be text can 
     be added that some other means may be used to deliver a CAP 
     message from CAP to aggregator.   

 2. I am assuming that any SIP device can use MESSAGE to 
     send CAP to PSAP. If so, some device will be able to handle 
     call-back and some won't. Do we need to distinguish devices 
     that will be issuing the MESSAGE to see whether call-back 
     can be established etc?  (I guess PSAP can look at allow header 
     to see if the device can accept INVITE etc.)
     
 3. For both cases, should there be any recommendation on how 
     sensor should behave in case 200 OK is not received or error 
     is received from downstream? Again related to the scoping of 
     the document, this may not be necessary if the main intent is 
     to recommend CAP document composition rule. 

 4. If non SIP device is used what should be set in "sender" of CAP? 
     What if the CAP message is sent by a sensor which doesn't support 
     SIP and it is the aggregator that acts as the SIP intermediary and 
     SIP endpoint?

 5. Use of P-Asserted-Identity doesn't provide any integrity so I would 
     take it out of section 6.3.

 6. Why is RFC3265/RFC3903 a normative reference? I think they 
     should be in an informative reference as there is no normative text 
     surrounding their uses. 

 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/
     RFC4119(PIDF-LO) be in a normative reference?

**Some nits**

  Section 6: 

  OLD ".. this document and the discussion in.."
  
  NEW ".. this document and are discussed in.."

  Section 6.2

  OLD "..alerts and reply them at a later time.."

  NEW "..alerts and replay them at a later time.."

Regards
  Shida

On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote:

> This message starts the Working Group Last Call for draft "Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)"  (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).
> 
> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)'
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Apr 2011 14:55:19 -0700

[BA] Overall, I echo Shida's comments about potential additional
usage scenarios and have a few additional comments about the
Security Considerations section. 

Specific comments below:

Abstract

   The Common Alerting Protocol (CAP) is a document format for
   exchanging emergency alerts and public warnings.  CAP is mainly used
   for conveying alerts and warnings between authorities and from
   authorities to citizen/individuals.  This document describes how
   data-only emergency alerts allow devices to issue alerts using the
   CAP document format.

[BA] It seems to me that the use of the term "Data-Only" may not be
appropriate to describe all the potential usage scenarios.   For
example, might it also not be possible to include CAP within an INVITE?
Suggestion is that the draft be renamed "CAP Emergency Alerts Using SIP",
and that the Abstract be changed as follows:

   The Common Alerting Protocol (CAP) is a document format for
   exchanging emergency alerts and public warnings.  CAP is mainly used
   for conveying alerts and warnings between authorities and from
   authorities to citizen/individuals.  This document describes how
   the CAP document format can be used to allow devices to issue
   emergency alerts.

----------------------------

   Data-only emergency alerts are similar to regular emergency calls in
   the sense that they require emergency call routing functionality and
   may even have the same location requirements.  On the other hand, the
   initial communication interaction will not lead to the establishment
   of a voice or video channel.

[BA] There are a number of potential uses for CAP, some of which could not
be characterized as "Data-only".  For example, CAP could be included in an
INVITE which also included an SDP offer.  Also an INVITE might be sent
without CAP and then when a response was received indicating that MESSAGE
was allowed then a CAP alert could subsequently be sent.  So I wouldn't
necessarily emphasize the "Data-only" aspect.  Suggested change:

   Eergency alerts containing data are similar to regular emergency calls in
   the sense that they require emergency call routing functionality and
   may even have the same location requirements.  On the other hand, the
   communication interaction may occur without establishment
   of a voice or video channel. 

----------------------------

   Based on the deployment experience with non-IP based systems we
   distinguish between two types of environments, namely (1) data-only
   emergency alerts that are targeted directly to a recipient
   responsible for evaluating the alerts and for taking the necessary
   steps, including triggering an emergency call towards a Public Safety
   Answering Point (PSAP) and (2) alerts that are targeted to a Service
   URN as used for regular IP-based emergency calls where the recipient
   is not known to the originator.  We describe these two cases in more
   detail in Section 3.

[BA] The term "emergency call" as opposed to "emergency alert" suggests 
that the aggregator could potentially convey the CAP message along with 
establishing non-data channels.  My suggestion is to rewrite as follows:

   Based on the deployment experience with non-IP based systems, two
   major deployment scenarios are envisaged:

   1) Emergency alerts containing only data are targeted to a 
      recipient responsible for evaluating the next steps, which
      could include:

         a. Sending an alert containing only data toward a Public
            Safety Answering Point (PSAP);
         b. Establishing an emergency call with a PSAP that could
            include audio/video as well as data

   2)  Emergency alerts targeted to a Service URN used for IP-based 
       emergency calls where the recipient is not known to 
       the originator.  In this scenario, the alert may contain
       only data (e.g. MESSAGE) or could be included along with
       establishment of an audio/video channel (e.g. INVITE)

We describe these two cases in more detail in Section 3.

----------------------------

Section 3

There is a basic issue in scenario described in Figure 2, which
is handling of failure conditions.

If we assume that the PSAPs do not deploy new capabilities uniformly,
then the sender may not know beforehand what capabilities the PSAP 
can support.   For example,  a given PSAP may or may not support MESSAGE,
may or may not support CAP or PIDF-LO, etc. 

If at all possible, you want to avoid multiple error-terminated conversations
between the sender and receiver, consuming precious time during an emergency. 

This is one argument for "silent call" approaches which utilize a
"known good" mechanism for initiating an emergency call (e.g. an INVITE),
then follow up with additional messages once the capabilities of
the responder are known (e.g. from an Allow: header). 

----------------------------

Section 4.1

      Alternatively, the SIP PUBLISH mechanism or other SIP messages
      could be used.  However, the usage of SIP MESSAGE is a simple
      enough approach from an implementation point of view.

[BA] I'm not thrilled with using PUBLISH, so I'd remove that but it
does occur to me that INVITE would make sense. 

----------------------------

Section 5

   Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse

[BA] Use of TCP transport makes sense, particularly in scenarios where both CAP
and a PIDF-LO might be included.  You might consider saying something about this
since TCP transport for MESSAGE is not that common today. 

----------------------------

Section 6.1

Does it really make sense to sign the CAP alert when the sender might be a sensor
that may not even by IP-connected, and the signer might be an aggregator with a
different identity from the <sender> or the identity in the From: field of the
SIP message?  If you are going to recommend that, you really need to describe
what if anything the receiver can do to validate the signature. 

----------------------------

Section 6.2

      Additionally, it is RECOMMENDED to make use of SIP security
      mechanisms, such as SIP Identity [RFC4474], to tie the CAP message
      to the SIP message.

[BA] Since the sender of the CAP message and the SIP message can be
different, RFC 4474 only can guarantee that the message isn't modified;
it doesn't really "tie them together".  For example, an attacker could
snoop on a signed CAP message, insert it in a SIP MESSAGE and then
use RFC 4474, and the sender wouldn't be able to verify that they are
unrelated though the sender would be accountable for the mis-behavior. 

----------------------------

Section 6.3

      For some types of data-only emergency calls author/originator and
      the receiver/recipient have a relationship with each other and
      hence it is possible (using cryptographic techniques) to verify
      whether a message was indeed issued by an authorized entity.
      Figure 1 is such an environment.  Standard SIP security mechanisms
      can be re-used for this purpose.  For example, identity based
      access control is a viable approach utilizing the asserted
      identity of the alert originator using P-Asserted-Identity
      [RFC3325] or SIP Identity [RFC4474].

[BA] What is the distinction between "forgery" and "Injecting false alerts"? 
Verifying the identity of the sender of the SIP message may tell you who
is accountable for sending the emergency alert, but that isn't the same
as verifying the authenticity of the alert itself.  

I might suggest that the threat model focus on the following instead:

1. Prevention of modification of data in transit (e.g. sending MESSAGE over TLS)
2. Verification of the sender identity (Section 6.3)
3. Signing of alerts (Section 6.1)

From: [email-masked]
Date: Wed, 20 Apr 2011 11:27:33 +0900
To: [email-masked]
Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01

I reviewed the document and followings are some comments/questions. 
 In general, I am having a hard time understanding the intent of the draft. Is it defining a CAP document composition rule (4.2) for delivering the CAP message from citizen to authority only? OR is it defining a SIP usage to transport CAP message as well? If it's latter I think more should be said about how SIP entities should behave. I understand it is an experimental document but I think we need to clarify the scope of the document somewhat. 
 1. For scenario 1, I really don't think in reality a sensor will be      implementing a SIP stack simply to support the transport of      CAP message, it just seems like an overkill. I understand how      aggregator to PSAP should be SIP to re-use what is defined      in Phone-BCP and pre-exising infrastructure. May be text can      be added that some other means may be used to deliver a CAP      message from CAP to aggregator.   
 2. I am assuming that any SIP device can use MESSAGE to      send CAP to PSAP. If so, some device will be able to handle      call-back and some won't. Do we need to distinguish devices      that will be issuing the MESSAGE to see whether call-back      can be established etc?  (I guess PSAP can look at allow header      to see if the device can accept INVITE etc.)      3. For both cases, should there be any recommendation on how      sensor should behave in case 200 OK is not received or error      is received from downstream? Again related to the scoping of      the document, this may not be necessary if the main intent is      to recommend CAP document composition rule. 
 4. If non SIP device is used what should be set in "sender" of CAP?      What if the CAP message is sent by a sensor which doesn't support      SIP and it is the aggregator that acts as the SIP intermediary and      SIP endpoint?
 5. Use of P-Asserted-Identity doesn't provide any integrity so I would      take it out of section 6.3.
 6. Why is RFC3265/RFC3903 a normative reference? I think they      should be in an informative reference as there is no normative text      surrounding their uses. 
 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/     RFC4119(PIDF-LO) be in a normative reference?

**Some nits**
  Section 6: 
  OLD ".. this document and the discussion in.."    NEW ".. this document and are discussed in.."
  Section 6.2
  OLD "..alerts and reply them at a later time.."
  NEW "..alerts and replay them at a later time.."

Regards  Shida
On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote:This message starts the Working Group Last Call for draft "Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)"  (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).