draft-ietf-msec-ipsec-tesla-00: regarding anti-replay protection

Hello all,

I have a question concerning
draft-ietf-msec-ipsec-tesla-00:

In the document it is stated that TESLA Authentication is
protected from
DoS attacks by non-group members through the usage of an
external
authentication transform using a symmetric-key MAC.

It is my understanding that this is not entirely true since
it leaves
the system vulnerable to replay-attacks to some extent (even
from
outsiders). All operations that have to be performed before
evaluating
the TESLA MAC and checking the sequence number, will have to
be done
even for replayed packets. This would also include the steps
incured by
the external authentication transform. Could this lead to a
*true* DoS
attack or is the computational overhead negligible?

For smaller groups it is possible to use the IPsec
anti-replay
protection (ESP sequence numbers) and keep track of each
senders state
but as noted in other documents this does not scale to
larger groups.
draft-ietf-msec-ipsec-extensions-06, Appendix 3 says that
IPsec
anti-replay protection should be disabled in large-scale
any-sender
multicast scenarios.

Can TESLA help mitigate the replay-attack problem in
situations where
ESP sequence numbering is not feasible and if so in what
way?

Regards,
Adrian


_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec

Hi Adrian,

I think that the group-keyed MAC protects the TESLA
receivers' buffers from
getting full of junk messages; in other words, it protects
against memory
exhaustion, rather than excessive computation.

David

On 9/24/07 8:45 AM, "Adrian-Ken Rüegsegger"
<rueegseggerswiss-it.ch> wrote:

> Hello all,
> 
> I have a question concerning
draft-ietf-msec-ipsec-tesla-00:
> 
> In the document it is stated that TESLA Authentication
is protected from
> DoS attacks by non-group members through the usage of
an external
> authentication transform using a symmetric-key MAC.
> 
> It is my understanding that this is not entirely true
since it leaves
> the system vulnerable to replay-attacks to some extent
(even from
> outsiders). All operations that have to be performed
before evaluating
> the TESLA MAC and checking the sequence number, will
have to be done
> even for replayed packets. This would also include the
steps incured by
> the external authentication transform. Could this lead
to a *true* DoS
> attack or is the computational overhead negligible?
> 
> For smaller groups it is possible to use the IPsec
anti-replay
> protection (ESP sequence numbers) and keep track of
each senders state
> but as noted in other documents this does not scale to
larger groups.
> draft-ietf-msec-ipsec-extensions-06, Appendix 3 says
that IPsec
> anti-replay protection should be disabled in
large-scale any-sender
> multicast scenarios.
> 
> Can TESLA help mitigate the replay-attack problem in
situations where
> ESP sequence numbering is not feasible and if so in
what way?
> 
> Regards,
> Adrian
> 
> 
> _______________________________________________
> MSEC mailing list
> MSECietf.org
> https://w
ww1.ietf.org/mailman/listinfo/msec

_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec