Document: draft-ietf-msec-tesla-intro-02.txt
Reviewer: Joel M. Halpern
Date: 13 augusti 2004 


At 12:54 PM 8/13/2004 +0200, Harald Tveit Alvestrand wrote:
>  o draft-ietf-msec-tesla-intro-02.txt
>    TESLA: Multicast Source Authentication Transform Introduction
>    (Informational) - 2 of 6
>    Token: Russ Housley
>    REVIEWER: Joel Halpern

This does appear to be ready for informational publication.  It is 
somewhat odd seeing an RFC that explicitly says "this is just an 
overview of the protocol, see these other publications for details.  
But I suppose it is useful.
(I am presuming that the crypto folks don't consider this harmful as an 
idea.)
Two moderate comments, and two minor comments.

Moderate:
1) This uses the old 2026 reference, and does not have an intellectual 
property statement.  Given that his is a protocol description for use 
by future standards work, I think the intellectual property statement 
is probably necessary.

2) There is one mention that receivers need to somehow protect 
themselves against a flood of bad packets.  There is no mention of how 
this might be done.  Similarly (possibly even really the same) 
conventional wisdom suggests that avoid a CPU DoS a receiver should be 
able to frequently discard bad packets before performing crypto 
operations on them.  Some mention of how this could be done would seem 
appropriate.


Some comments for clarification, particularly if updates need to be 
done:
3) I started to get distracted about whether this applied to all 
multicast, to non-SSM only, to systems without authenticated IGRP, etc. 
  When I reached the treat model I realized it implicitly aims at all 
multicasts because of the threat model (the attacker can do anything to 
the network.)  I would probably have avoided some confusion if that 
model could have been mentioned earlier.  (I was mistakenly thinking 
this was aimed at the threat of a masquerading external sender.)

4) The "threat model" section is actually both threat model and 
environmental assumptions.  (There is a fast, low delay, network 
assumption in there.)  I think, but am not sure, that high delay may 
impact how long the gap between the packet and its authenticator is.

Yours,
Joel