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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Aug 2004 19:14:02 +0200

Iljitsch,

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;

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

Is that a correct summary?

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. It is true that two endpoints may
have more than one session between them, and that is sufficient
for your argument.

> 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.

    Brian

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Thoughts About Layer 3.5 Redirection Security
> 	Author(s)	: I. van Beijnum
> 	Filename	: draft-van-beijnum-multi6-redirection-00.txt
> 	Pages		: 5
> 	Date		: 2004-8-16
> 	
> The new multi6 design team as of august 2004 is chartered to explore
> multihoming by means of a "layer 3.5 wedge" that allows unmodified
> applications and transport protocols to become address agile. 
> 
> In order to do this, the two hosts involved must communicate certain
> parameters. The exact nature of this communication isn't specified at
> this time. However, this document discusses certain security issues
> pertaining to such communication.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-redirection-00.txt

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 19 Aug 2004 09:53:41 +0200

> adding multihoming-specific threats makes things no worse;

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

> Is that a correct summary?

Yes.

> I don't think that is generally true.

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

> It is true that two endpoints may

Yes.

> presumably break it for all of them, so again they share fate

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?  :-)