Subject: [earlywarning] Review of draft-rosen-atoca-cap

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Jul 2010 14:40:23 +0800

This is my first read of a SIP-CAP document in any detail.  On the whole, the draft is well-written and structured, but it needs a lot of work.

There's plenty of meat in here for a working group effort.  

Comments:

Why does this proposal not use RFC 4660 and RFC 4661?  The <warning-registration> looks very much like a trigger extension.  The <service> looks much like a what extension, or...

Why does this proposal not use resource lists (RFC 4662)?  Each service could be considered as a different target.  (Drawback: creation of a resource list is not specified in RFC 4662).  (Drawback: complexity.)

How do you propose to address the problem of multiple alerts?  Based on the mechanism that you propose, it is possible for multiple alerts to be active.  The alert element at the root of a CAP message contains information for a single event.  Are these to be combined with multipart MIME (multipart/mixed?).

Why not allow forking for this package?  It seems that this event package is particularly well suited to forking.  It's also evident that merging of state is trivial for this sort of data.  Given that a single SUBSCRIBE might include multiple services and locations, it seems equally logical to allow multiple sources to provide alerts, with the initial target serving an aggregation function.

The PUBLISH mechanism needs further thought - depending on what the architecture looks like.  As I understand, it's possible that there are multiple EPAs for a given ESC.  The one logical resource (SIP entity) might collate state for many different services (or not, see above).  A PUBLISH to this resource should not require that the EPA provide complete state - instead, a PUBLISH containing a single CAP document should suffice.  The behaviour of the ESC should be to add the CAP document to the set of alerts that it maintains.

There is zero discussion of the operational impacts.  It seems that there is a need to understand the implications of creating an alert - how many people it might be forwarded to, etc...

The security section needs a lot of work.

Identify the threat model: from what I read, this basically reduces to forgery of alerts.  A discussion on how a single PUBLISH request turns into potentially millions of NOTIFY requests would have seemed appropriate.

Replay attacks reduce to forgery due to the time and serial number parameters in the alerts.

It seems that there are two mechanisms proposed for countering forgery: using digital signatures or channel security (TLS).  The first goes all the way back to the source; the second looks at the last hop and relies on a transitive chain of trust.

The structure of the section is such that these messages are obfuscated with a lot of noise.  The MITM attack is especially poorly defined.  Most of the countermeasures are useless.  The signature mechanism smells of hope, but fails to identify any practical solution.

I'd also like to provide some comments on CAP.  With a few minor tweaks, it could fit a lot better with existing IETF work.

Nits:

Section 1: The idea considerations section seems obvious when you know RFC 3903 well, but it's actually pretty confusing if you don’t.

  "... any event
   package intended to be used in conjunction with the SIP PUBLISH
   method has to include a considerations section."

My first reaction was: considerations about what?  This could be clarified, but what I'd prefer is that you simply provided the requested content.  No need to explain that you do this because RFC 3903 told you to.

The same sort of (unnecessary) appeal to authority is used extensively.  A lot of text could be safely cut.

Section 3.5: The default for the header should also include a charset=utf-8 parameter, as recommended by RFC 3023.

Section 3.6:  This statement seems out of place.  There needs to be more rigorous discussion of architecture than this:

   Notifiers will typically act as Event State Compositors (ESC) and
   thus will learn the 'common-alerting-protocol' event state via
   PUBLISH requests sent from authorized [EPAs].

The word "typically" is a problem here.  Why not just say that the ESC and Notifier roles are the same.  A Notifier might also be an EPA, or they might accept PUBLISH requests from authorized EPAs.

Section 3.7:  This seems like a copy-paste type error:

   In the case of a pending subscription, when final authorization is
   determined, a NOTIFY can be sent.  If the result of the authorization
   decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
   complete CAP document.

As the draft describes, it's unlikely that there will be state at the time that the subscription is created.  This statement should also reflect that.

Section 3.11:  RFC 3265 requests more detail than what is provided, especially since state agents are being permitted.

Section 3.13: CAP documents can be large - if they contain a <derefUri> element.  Should this be prohibited or recommended against?

Section 3.14: Should the PUBLISH "considerations" be split into their own section separate to the SUB/NOT stuff?

Section 3.15: This section doesn't make sense: what does the PUBLISH response contain?  An empty body seems like a reasonable option.

The example in Section 4 shows a CAP document, not a complete example SUBSCRIBE/PUBLISH/NOTIFY.

Section 6.3: This would be clearer if the services were described as complete URNs, e.g. urn:service:warning.cbrne (btw, that's a painful acronym to remember).

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Jul 2010 14:22:37 +0200

Hi Martin,

this is a fairly extensive review. Let me try to provide a bit of 
background.

The first challenge we ran into was the lack of a definition of alerts. 
We tried to put a list of alert types in 
http://tools.ietf.org/html/draft-rosen-atoca-server-discovery-00 (see 
Section 6.1) but faced a lot of resistance on the mailing list (see 
http://www.ietf.org/mail-archive/web/earlywarning/current/msg00130.html).

Before this aspect is addressed it is a bit difficult to say whether 
filters, service URNs, resource lists, etc. are the right approach.

The current version of the document hints to the need to provide some 
additional information in the body of the SUBSCRIBE to specify the type 
of alert in more detail but the proposal clearly is a placeholder.  
Nevertheless, I like the idea of using filters even though I was already 
wondering with the location-filter work in GEOPRIV whether there is a 
more elegant and more sophistcated way to deal with it.

As you noticed there are some aspects not well enough described, such as 
the operational aspects. Forking is a copy-and-paste error from the 
event package this document was created from.

On the security aspects: There are really only 2 types of trust models, 
namely end-to-end and hop-by-hop (with transitive trust). I would hope 
for an end-to-end model knowing that it will not be provided in almost 
all deployment environments. When I look at the way how alerts are 
distributed today then I doubt that even a hop-by-hop model with 
cryptographic protection is super realistic to assume either.

The described threats focus a lot on the distribution rather the 
publication. I believe we can probably re-use text from the email world 
regarding the threats. Will search for it.

Ciao
Hannes

On 14.07.2010 08:40, Thomson, Martin wrote:
> Why does this proposal not use RFC 4660 and RFC 4661?  The<warning-registration>  looks very much like a trigger extension.  The<service>  looks much like a what extension, or...
>
> Section 3.13: CAP documents can be large - if they contain a<derefUri>  element.  Should this be prohibited or recommended against?
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 08:55:57 +0800

Thanks for taking the time Hannes,

I really wanted to highlight what I thought needed work.  We're obviously still at a very early stage in this work.

> http://www.ietf.org/mail-
> archive/web/earlywarning/current/msg00130.html).
> 

The alternative is tougher, but potentially more robust.  You have a single service with no associated taxonomy: urn:service:warning

The results of a query on this service returns all applicable services for the area.  Each contains a description.  The user chooses the warning services based on these descriptions.

There are costs, but it avoids the sticky taxonomy problem.

Another approach is to allow for services to be identified with proprietary URI identifiers.  These generic identifiers could be discovered using out-of-band means (side of bus, web search).  Then LoST doesn't come into it at all, SIP routing (possibly location-based) does all the hard work.  It's probably not-cool if we don't use LoST though.  

--Martin

...snipped...

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jul 2010 11:15:22 +0200

Hi Martin, 

> I really wanted to highlight what I thought needed work.  We're obviously
> still at a very early stage in this work.
> 
> The alternative is tougher, but potentially more robust.  You have a
> single service with no associated taxonomy: urn:service:warning
> 
> The results of a query on this service returns all applicable services for
> the area.  Each contains a description.  The user chooses the warning
> services based on these descriptions.
> 

Interesting idea. Would be worthwhile to check how many different warning alert one would get with such an approach (in a specific geographical area). 

> 
> Another approach is to allow for services to be identified with
> proprietary URI identifiers.  These generic identifiers could be discovered using
> out-of-band means (side of bus, web search).  Then LoST doesn't come into it
> at all, SIP routing (possibly location-based) does all the hard work.  It's
> probably not-cool if we don't use LoST though.  

Probably the right way is often somewhere in the middle. Currently the ITU-T tries to establish a registry of organizations distributing alerts. One can obviously retrieve the list of organizations from there. A user would not want to do that, however. Instead, they would more likely opt for two approaches: (a) use a preconfigured list of organizations, or (b) use an aggregator that does these types of things for them. 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 22 Jul 2010 08:32:12 +0800

> Interesting idea. Would be worthwhile to check how many different
> warning alert one would get with such an approach (in a specific
> geographical area).
 
Absolutely.  Scale is certainly a factor in all this.

> Probably the right way is often somewhere in the middle. Currently the
> ITU-T tries to establish a registry of organizations distributing
> alerts. One can obviously retrieve the list of organizations from
> there. A user would not want to do that, however. Instead, they would
> more likely opt for two approaches: (a) use a preconfigured list of
> organizations, or (b) use an aggregator that does these types of things
> for them.

Sure.  The same types of mechanisms we use for discovering ...say entomology interest sites on the web could be used.  There might be well known aggregators or search sites, or it could be a system of referrals (each service might maintain a page that points to other similar services).

I'm just opening up the field a little.  I don't want to see a solution that is more technology/protocol heavy than it needs to be.

--Martin