Subject: [RAM] Re: Should we provide protection against time shifted attacks?

From: RJ Atkinson <[email-masked]>
Date: Sun, 7 Jan 2007 18:47:42 -0500

Marcelo,

	I know of practical "Time Shifted Attacks" for the currently
deployed IPv4 Internet.

	I also know of practical "3rd Party DoS Attacks" for the
currently deployed IPv4 Internet.

	If some RFC really asserts that none exist, then either
there was an editing error someplace or someone was confused.

Yours,

Ran

PS:	I don't discuss mechanisms for active attacks on any deployed
	network on any public mailing list -- except by way of citing
	already published papers by other people.  That's been my
	policy for many years and won't be changing anytime soon.

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 8 Jan 2007 08:13:39 +0200

Ran,

> 	I know of practical "Time Shifted Attacks" for the currently

This was news to me -- I must be ignorant.

Or, to be more precise, I know of one that allows time shifting of  
minutes or at most hours, depending of deployed configuration  
parameters, but not of longer.  When designing MIPv6, we ended up  
allowing time shifting of minutes, by default.

> currently deployed IPv4 Internet.

Me too.

But even so, do you think we should design new mechanism that we  
know, at the design time, to embed new ways of launching such attacks?

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 8 Jan 2007 10:05:10 -0500

> allowing time shifting of minutes, by default.

	Saying "minutes or at most hours" is not fundamentally different
from what I've said -- and that is VERY different from "no attacks
exist", which is what Marcelo was claiming for the current IPv4  
Internet.

	If we can live with that for MIPv6 (and I think the upper
bound for MIPv6 is hours not minutes, by the way), then that same
level of risk ought to be completely acceptable for some other
approach, change, or enhancement for the Internet.

> know, at the design time, to embed new ways of launching such attacks?

	I think that really is the wrong question.  More secure
than at present is "nice to have" rather than "MUST".  Further,
my own experience is that any sort of system that has increased
security will also become more brittle.   There might be exceptions
to that principle, but I can't immediately think of any.  For
example, requiring cryptographic authentication of some message
often creates a new (D)DOS vector.[1]

	The question ought to be is whether some new scheme or
enhancement is LESS SECURE than the currently deployed IPv4 Internet
or the currently deployed IPv6 Internet.  As long as the new scheme
is NOT less secure, that ought to be sufficient.

	Fundamentally, if folks think that the current risks are NOT
acceptable, then they ought to be criticising things like MIPv6 on
insecurity grounds and ought to be focusing on fixing the current
risks in the currently deployed Internet as their priority.

Yours,

Ran

[1] Details of how the attack would work are deliberately omitted.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Jan 2007 17:09:18 +0100

On 2007-01-08 16:05, RJ Atkinson wrote:
...
> is NOT less secure, that ought to be sufficient.

Well, it meets the "first, do no harm" principle, but people who
believe the Internet infrastructure is unacceptably insecure today
may not agree. Also, it seems hard to judge - if a new feature
introduces a qualitatively different threat, how can we assert
that it is not less secure?

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 08 Jan 2007 17:11:55 +0100

> that it is not less secure?

And are "we" the right people to make that decision (for some 
ISOC-related value of "we")?

Eliot

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 9 Jan 2007 13:32:40 +0100

Hi Ran,

> there was an editing error someplace or someone was confused.

interesting...

as i mentioned before, the goal of both MIPv6 Route optimization design 
and shim6 design was to not to introduce new vulnerabilities and in 
both cases the community has considered that the time shifted attacks 
were something new that was possible with MIP/shim6 if not properly 
secured and that the resulting flooding attacks of a non properly 
secured MIP/shim6 portocol would be much more dangerous than the ones 
available today.

however, it is possible that the assesment of the current situation and 
current attacks was flawed and there was some current vulnerabilities 
missing (as you say that such attacks are possible in the current 
internet)

If this is the case, and we agree that the goal in terms of security is 
to not to introduce new vulnerabilities, then it would be ok to design 
an ID/loc split approach that doesn't provide protection against this 
type of attacks. Such solutions would be certainly simpler than the 
ones resulting when we take in account the aforementioned attacks.

SO imho determining the security level desired for the solution and 
assessing the possible attacks in the current internet is a critical 
point to design and evaluate different approaches for this.

> 	policy for many years and won't be changing anytime soon.

i can certainly see merit in this attitude, but how do you suggest we 
move forward, in particular how should be asses the current 
vulnerabilties of the internet and we reach concensous on this point if 
we do not discuss it on the ml?.... any suggestion?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 9 Jan 2007 14:48:05 +0100

El 08/01/2007, a las 16:05, RJ Atkinson escribió:

> bound for MIPv6 is hours not minutes, by the way),

no, the upper limit for mipv6 is 7 minutes (this is the lifetime of the 
BCE when it is secured using the RR check) AFAIK

i can live with a solution that allows time shifted attacks of 
minutes.... perhaps a bit more than 7 minutes, but i don't think we 
should allow something like 10 hours...

>  then that same

agree MIPv6 security level is appropriate

> is NOT less secure, that ought to be sufficient.

i am ok with this

mipv6 security level can be used as the minimum bar

Regards, marcelo