Re: how secure mh should be? Re: identifiers and security

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Iljitsch,

i think we agree more than i thought :-)

El 01/07/2004, a las 12:23, Iljitsch van Beijnum escribió:

> On 1-jul-04, at 11:46, marcelo bagnulo braun wrote:
>
> > imho is important to reach a common criteria here.
>
> Yes. But in order to do that, we need to analyze the situation so we 
> can make a proper decision.
>
> > i think that the minimum goal should be that the resulting solution 
> > should be as secure as current fixed, single homed IPv6 internet.
>
> > As you say, i wouldn't mind if the result is a bit more secure, but i 
> > wouldn't require it
>
> I think the first statement doesn't really provide much guidance:

Well, i think it in the following way.
In the new environment, where multihomed sites implement the proposed 
solution,  is it possible to launch new attacks that were not possible 
in the previous Internet (i.e. the internet without the multi6 
solution)?

If the answer is yes, then we have to carefully understand the scope of 
these attacks and see if this is acceptable

>  whatever we do, multihoming makes things different, and whether 
> that's worse or not isn't necessarily something we automatically agree 
> on.

agree that there is no automatic agreeing when evaluating the new 
possible attacks

>  That is, unless multihoming actually makes everything more secure. 
> Now that can't be a bad thing, can it? Actually: yes. Too much 
> security is harmful. In order to be secure, you must either implement 
> additional mechanisms, which requires additional complexity, bandwidth 
> and/or computation. In many cases that's just fine: if my email 
> message becomes 7k rather than 4k and it takes 50 ms to decode it, who 
> cares? But if I want to transmit a 8 Gbps stream from my radio 
> astronomy observatory to a remote computing facilty, I don't have the 
> luxury to do even an MD5 over that data. Insisting on security when 
> the necessary mechanisms aren't available or can't be applied means 
> making communication impossible.

agree with this point.
again, the cost of the enhanced security has to be evaluated in each 
case

> (BTW, that's one of my issues with Secure BGP / secure origin BGP: if 
> you require everything to be signed there WILL be times when "good" 
> communications will be impossible because of certificate problems. And 
> it's not like there are never problems with certificates...)
>
> Remember, most traffic flowing over the internet is completely 
> unprotected and people don't seem to be bothered by that too much.
>
> Going back to Erik's analogy of someone looking through the window 
> into your office. I think we can agree that giving such a person the 
> opportunity to install a device that allows her to keep observing what 
> happens long after she's left is unacceptable. On the other hand, the 
> owner of the office does have papers out that are visible through the 
> window, so they are taking a risk and it's not our place to take 
> exception to that. What I've been saying for a while now is that 
> redirecting individual unprotected sessions isn't really worse than 
> what an attacker can do today.

agree
redirection of a single connection by an on path attacker may be 
acceptable, but redirecting all future connection is not acceptable

Bottom line: the goal is to preserve actual security: anything more or 
less secure has to be evaluated in particular, agree?

Regards, marcelo

> In our analogy: today someone can look through the window and read 
> (for instance) the pages of a book that is open in our proverbial 
> office. Redirecting individual sessions would be comparable to someone 
> being able to read the entire book rather than only the pages that are 
> visible at that moment. Now it's possible to argue that this is worse, 
> but my position is that if the book was confidential, it shouldn't 
> have been open in front of the window so people could read a couple of 
> pages in the first place. So there are three possible cases:
>
> 1. The book is confidential and the user wants to keep it that way = 
> IPsec/TLS. Our MH mechanisms should protect these against redirection.
> 2. The book is confidential but the user has it open in view of the 
> window anyway = no IPsec/TLS and wireless. It doesn't make sense to 
> consider this situation as there is leakage of confidential 
> information regardless, the only question is whether it's going to be 
> a bit more.
> 3. The contents of the book aren't confidential = redirecting isn't 
> worse than breaking (if they can steal your book, why bother making 
> sure they can't read it if they can pick it up at the bookstore 
> anyway?).