Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

> On May 5, 2016, at 1:00 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 
> On 05/05/16 05:31, Alissa Cooper wrote:
>> 
>>> On May 4, 2016, at 11:53 AM, Stephen Farrell
>>> <[e-mail]> wrote:
>>> 
>>> 
>>> Hiya,
>>> 
>>> Please do continue the discussion all, but just on one aspect of 
>>> this...
>>> 
>>> On 04/05/16 19:18, Alissa Cooper wrote:
>>>> Even if only a single application ever defines a priority scheme,
>>>> a network where clients can’t be trusted could fall victim to an
>>>> attacker who inflates the priority of his traffic to try to
>>>> prevent emergency calls/first responders from getting priority
>>>> treatment.
>>> 
>>> My understanding of Diameter deployments is that they are pretty 
>>> much all done so that any node can play all sorts of games and 
>>> there are no protocol mechanisms other than hop-by-hop TLS or
>>> IPsec to control that. I'm not even sure how much those are
>>> deployed, even in cases where cryptographic keys are passed in
>>> Diameter messages. (And that's when the base protocol spec says you
>>> MUST use TLS in such cases. [1])
>>> 
>>> So DRMP and DOIC are by far not the most attractive target here.
>> 
>> But my point was specifically about how the motivation for DRMP is
>> tied to the first responder and emergency use cases. When a
>> capability is defined specifically for those uses, people (or, say,
>> regulators) tend to expect it to work. So if there is a class of
>> cases where it won’t work at all — even if the net effect is just
>> that requests get treated on a best efforts basis the same as they do
>> today, not that some requests get starved — it’s worth being very
>> explicit about that. I’m sure there are other attacks that could
>> target these uses in the absence of DRMP, but that isn’t a reason to
>> gloss over the DRMP-specific issue in this spec.
> 
> Sure. But I'm not clear what's being glossed over. If what you mean
> is that some more text is needed in section 11 to discuss emergency
> use cases, that'd be fine, (and suggestions welcome) but I thought
> that that potential attack was covered there already, even if not
> explicitly called out.

I think the gap is in Section 5, where it should be noted that in order for priority information to be reliably usable in the way that use cases 5.1 and 5.2 call for, the Diameter nodes sending and consuming it must have pre-established trust relationships of the sort described in Section 11.

Alissa

> 
> Cheers,
> S.
> 
>> 
>> Alissa
>> 
>>> The DIME WG are attempting to address that via [2] but I'm not sure
>>> if we ought be hugely hopeful of that being implemented or deployed
>>> either.
>>> 
>>> It might help if someone more familiar with deployments can correct
>>> or confirm the above.
>>> 
>>> That doesn't affect the issue of potentially un-coordinated uses of
>>> different priorities across multiple Diameter applications, which
>>> seems like it is worth saying more about, but I'd have to say that
>>> uses of DRMP as an attack vector aren't that compelling from what I
>>> know, and the WG are attempting to at least document mechanisms
>>> that would provide relevant protocol countermeasures for the base
>>> protocol.
>>> 
>>> Cheers, S.
>>> 
>>> [1] https://tools.ietf.org/html/rfc6733#section-13.3 [2]
>>> https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req
>>> 
>>> 
>> 
>