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

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: 
whatever we do, multihoming makes things different, and whether that's 
worse or not isn't necessarily something we automatically agree on. 
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.

(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. 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?).