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

[Brian E Carpenter <brc@zurich.ibm.com>]

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

Internet-Drafts@ietf.org 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