Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long)

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Tue, 31 Aug 2004 15:50:51 +0200

Hi
I've not gone through all the mails (just arrived from vacation), 
however some thoughts..

> 
> Jumping into a very long discussion, wanted to say few short things:
> 
> 1. I think that the TESLA intro draft should contain a better
> comparative discussion of anti-DOS methods, including weaknesses and
> strengths, and recommendations for use in different scenarios.
> however I DONT think that the intro draft should (or can) 
> mandate any one
> method. Remember, this is an informational draft, not a dtandard.
> 
> In contrast, tesla-srtp, and also the comingrealsoonnow tesla-esp are
> standards, and therefore they should each choose one DOS 
> protection method,
> that is suitable to their respective scenarios.
> 
> I am ok with tesla-srtp using the current external MAC 
> method, especially
> since SRTP already has an external MAC mechanism in place. 
> But I dont feel
> strongly here at all, mainly since none of the suggested methods is
> completely superior to other methods. all have their own strengths and
> weaknesses. I'd thus opt for doing the simplest thing... whatever that
> might be.
> 
> That said, I think it is reasonable to reduce the extenal MAC 
> in tesla-srtp to
> RECOMMENDED. Indeed, as Bob points out, in some scenarios it might be
> totally unneeded and only be a babdwidth deadweitght. (still, 
> the security
> considerations section ahould make it crystal clear what are 
> the tradeoffs
> here.

We discussed of the possibility of making the external 
MAC optional, though we were mainly waiting for feedback from the TESLA
authors. I'm personally ok with RECOMMENDED (actually, I'd prefer it), 
and I'd encourage the TESLA authors to discuss the DoS issue in the 
base TESLA draft.    

> 
> 2. I think that Bob's idea of having the receiver infer the interval
> number from the RTP timestamp may work in some/many cases. 
> But it might
> make the programming more delicate and harder to get right. 
> One potential
> solution is just to opt for a more robust design at the price 
> of extra 4
> bytes p.p. altenratively, we can make  the interval number 
> optional and
> leave it up to the implementation whether it wants to save the extra 4
> bytes or not.

That I know, the RTP timestamp is a weird beast. It is not monotonically
increasing. Subsequent packets can have the same timestamp value, or there 
could be big jumps (e.g. if there is silent but it is not transmitted), 
and the value can even decrease. I feel better with the TESLA index ;o)

Cheers
/E 

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