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

Hannes Tschofenig <> Tue, 20 July 2010 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A6F13A679C for <>; Tue, 20 Jul 2010 05:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XJRNM8LgbDuA for <>; Tue, 20 Jul 2010 05:21:43 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9096F3A6A46 for <>; Tue, 20 Jul 2010 05:21:42 -0700 (PDT)
Received: (qmail invoked by alias); 20 Jul 2010 12:21:57 -0000
Received: from unknown (EHLO []) [] by (mp035) with SMTP; 20 Jul 2010 14:21:57 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19fhcsxyJlf4dKaWVVe69FmIPDL2gpUbzSOWbR5m/ eqUGzpNam7LAz2
Message-ID: <>
Date: Tue, 20 Jul 2010 14:22:37 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: "Thomson, Martin" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "Rosen, Brian" <>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <>, "" <>
Subject: Re: [earlywarning] Review of draft-rosen-atoca-cap
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Jul 2010 12:21:48 -0000

Hi Martin,

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

The first challenge we ran into was the lack of a definition of alerts. 
We tried to put a list of alert types in (see 
Section 6.1) but faced a lot of resistance on the mailing list (see

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.


On 14.07.2010 08:40, Thomson, Martin wrote:
> 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).
> _______________________________________________
> earlywarning mailing list