Subject: [MMUSIC] Re: FW: Security requirements review

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 May 2004 22:00:31 +0300

Hi,

a couple of comments:

I would clarify what you had in mind when you wrote the following 
requirement:

REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
    resources of IMG entities by flooding them with IMG metadata.

What do you mean by "avoid"? Do you mean that the entity should be able 
to run in a stateless mode? Or that it should be able to identify evil 
packets and discard their data? or...?

You should clarify both requirements in Section 6.5 (Replay Attacks):

REQ REP-1: IMG metadata MUST be protected against partial or full
    replacement of newer ("current") versions by older ones.

REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
    the IMG operations.

Do you mean that you have to bundle somehow the metadata with the 
delivery mechanism? Let's say I receive metadata and I send it to 
another user without knowing that a newer version of the metadata is 
available... should the other user be able to detect this "reply 
attack"? I guess that an explanatory paragraph would help understand 
what these requirements really mean.

Thanks,

Gonzalo

[email-masked] wrote:

> Hi
> 
> Because I found that you have somehow been active on security issues related to MMUSIC, it would be fantastic if you would have a look at the security requirements in:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-03.txt
> ..and send comments back (CC MMUSIC email list too if possible).
> 
> The document concerns "Requirements for Internet Media Guides" (IMGs).
> 
> This document has completed WGLC and we are thinking about a final sanity check that nothing crazy slipped past the authors, reviewers and numerous editions before handing over to the IESG (as a kindness towards the IESG :)  If you spot any impossible, unnecessary or questionable requirements please highlight them. (Naturally we're happy that the document is flawless, but once by your expert eyes would be very reassuring).
> 
> The security sanity check concerns chapter 6 of the document (maybe I'm pushing my luck to say comments on other parts are always welcome too).
> 
> Thanks for any ideas you can offer.
> 
> Cheers, Rod Walsh.
> 
> 
> PS rather than filling your inbox with lots of background I hope you are happy to ask in case you haven't had chance to follow the IMG work so far.
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked]
Date: Wed, 12 May 2004 13:07:23 +0300

Hi Gonzalo

Thanks for the comments and questions. Please see in-line...

> packets and discard their data? or...?

These are both good ideas as options for implementing some kind of protection against DoS attacks.

Here we say "avoid" without specifying how to avoid. Whether the IMG entity runs in stateless mode or not is an implementation matter so it is not a requirement to be able to run in stateless mode (other solutions are allowed). The same is true of discarding evil packets. These are more security considerations of any solution proposed, and not so much considerations of the requirements, but it is still relevant commentary. I suggest that we add the following commentary after REQ DOS-3...

  As an example, two potential solutions which may be considered are
  running an IMG entity in stateless mode or identification and
  discarding of malicious packets by an IMG entity.

> what these requirements really mean.

Good point. I think the following text clarifies the meaning for REQ REP-1:

  In a system with multiple senders it may not be feasible to prevent
  some senders delivering older versions of metadata than others - as
  a result of imperfect sender-sender data consistency. IMG receivers
  shall tolerate both cases of friendly and malicious sending of older
  versions without damaging their latest available version.

And the following clarification for REQ REP-2:

  The level of threat from replay attacks varies very much depending
  on system scale and how well defined or open it is. Thus mitigating
  relay attacks may lead to different solutions for different systems,
  independent of the basic delivery method and metadata definitions.
  A system with multiple senders presents a more challenging scenario
  for handling replay attacks. As an example, bundling metadata with
  a security mechanism is one potential solution.

How does that sound? Anyone with better clarification text?

Cheers, Rod.