[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-van-beijnum-multi6-redirection-00.txt

On 18-aug-04, at 19:14, Brian E Carpenter wrote:

Interesting. If I understand you correctly, you are saying: 

1) if a traffic flow is not protected by IPSEC or TLS,
it is intrinsically subject to so many attacks that
adding multihoming-specific threats makes things no worse;


Right. Slightly different of course, but not really worse.

and 2) if the flow is protected, that same protection is
sufficient to protect the exchange of multihoming information.

Is that a correct summary? 

Yes.

If so, I think you are slightly wrong in this:

3.7 Per-session multihoming signaling
This document only describes the issues pertaining to a single session
or association. In reality, two endpoints are extremely likely to have a
larger number of sessions between them.

I don't think that is generally true. 

Send me your endpoints and I will do measurements.  :-)

It is true that two endpoints may
have more than one session between them, and that is sufficient
for your argument.


Yes.

In this case each session must
receive its own multihoming processing, in order to make sure that a
successful attack against one session doesn't lead to long-time
redirection of additional sessions between the same hosts later.


I think the correct statement is that the unprotected sessions
(i.e. those without TLS or IPSEC) share fate under attack,
since an attack against any one of those sessions can trivially
become an attack against all of them. But I don't see why protected
sessions can't share state, since they are indeed protected.


If an attacker can break that protection for one session, she can
presumably break it for all of them, so again they share fate
whatever you do.

The thing we want to avoid is that an attacker manages to sniff some traffic for a short time, and then gets to redirect not only current sessions, but also new ones set up after the attacker can no longer sniff. (Which would happen if all of this worked per address rather than "per session".)

I think it's not only possible to share state between protected sessions, but also between non-protected sessions. This should eliminate much of the overhead of having to work per-session. And the most interesting case would be to share state from protected sessions with unprotected sessions so these are now also better protected (although still vulnerable to regular unprotected IP attacks).

Are you sure you don't want to be on the design team list?  :-)