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

["Thomson, Martin" <[e-mail]>]

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).