Subject: [MSEC] Review of changes in draft-ietf-msec-srtp-tesla-02.txt

From: Bob Briscoe <[email-masked]>
Date: Sun, 28 Nov 2004 23:10:34 +0000

Mark, Elisabetta,

1/ In the new text in section 5.
"...Since a key is repeated across packets in an interval, TESLA is robust 
to packet loss...."

This understates TESLA's loss tolerance, so may confuse people trying to 
understand applicability. Should read something like:

"...Since a key in a lost packet can be derived from a future packet, TESLA 
is robust to packet loss...."

2/ I still disagree with keeping the SRTP (external) MAC mandatory...

...But my argument relies on the technique to protect against DoS you 
haven't seen in detail yet. I've added this to 
draft-ietf-msec-tesla-intro-04  (as well as fixing all the IESG comments). 
I've just sent it to my TESLA co-authors for agreement. I believe it allows 
us to state very strong DoS prevention properties. Hopefully I should be 
able to send it to the list within the week.

3/ Other than the comment in the previous mail on "MUST/MAY discard 
unverifiable", these are the only problems I can find with a nice clean, 
clear draft.

Thanks

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196 

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Mon, 29 Nov 2004 11:32:59 +0100

Hi Bob,
first of all many thanks for your comments.

>is robust to packet loss...."

ok

>able to send it to the list within the week.

The external MAC is mandatory only for SRTCP, it is optional for SRTP. 
We thought this was a good choice, mainly for two reasons:
- the RTCP packet is generally long and not that frequent. This means 
that the bandwidth issue is not of such a high concern as instead it is 
for RTP packets. We can live with 4 extra bytes in SRTCP.
- we wanted to maintain the choice done in the SRTP main spec (auth tag
mandatory for SRTCP and optional for SRTP).
Those were the motivations for the current normative language. 

Cheers
/E

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 29 Nov 2004 12:55:23 +0000

Elisabetta,

>Those were the motivations for the current normative language.

OK, I admit to being to hasty. I hadn't noticed the reference to the "SRTP 
(external) MAC" being mandatory was only in the "SRTCP packet format" section.

I'm glad to see that, for SRTP packet format, the SRTP MAC is now 
recommended, not mandatory.

Regarding SRTCP, I can see the rationale you lay out. And I certainly 
cannot think of a scalable alternatiev for authenticating each receiver 
separately to the source.

But, I can still see scenarios where mandating a group keyed MAC, even just 
for SRTCP, will be seen by implementors as just "baggage to comply with the 
standard", involving creating disseminating, re-keying and managing a group 
key when it provides no useful protection. Think for example of Internet 
TV. A shared secret really is an oxymoron when millions of people share it.

3/ So we are left with a DoS vulnerability for the source from group 
members (who can't be identified individually) flooding it with SRTCP 
reports appearing to come from different receivers - possibly bogus ones 
that cause the session to slow to a snail-pace. This would be nasty for 
Internet TV, say.

But I can't think how to fix this easily. The cookie approach would help. 
Where, when under attack, the source could switch the session to a mode 
where each SRTCP report should be preceded by a request to make a report. 
It would reply with a cookie, which it would check against the next 
incoming RTCP report from that receiver. At least this would validate the 
IP addresses of the receivers making reports, as a deterrent.

But this cookie approach would have to go into base SRTP (I'm not even sure 
that's the best place for it). It's nothing specific to SRTP-TESLA.

Bob