RE: security requirement for multi6

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Masataka,

> Here is the security requirement for multihoming with or without
> DNS.
>
> A point is that a set of locators of a host is stable, which
> makes the requirement different from that for mobility.

This assumption does not take into account a renumbering event, but i agree
that this is common scenario.

>
> That is, if a set of all the locators of a host is obtained
> with certain security, it's OK. Peer of the host should accept
> any locator in the set.
>

Agree

> With DNS, a set of all the locators of a host can be simply
> obtained as a RR set with reasonable security. Those insisting
> on more complex security may use secure DNS (though secure DNS
> is impractical to deploy).
>

agree

> Without DNS, a cookie and a set of all the locators of a
> host should be exchanged with the peer as 3 way handshake
> at the beginning of a communication. The cookie is to prevent
> DoS with source address spoofing. The handshaking may be
> performed as a special protocol or piggybacked on an existing
> protocol. Especially, the handshaking may be piggybacked on
> initial 3 way handshaking of TCP with sequence numbers as cookies.
>

Could you expand a little bit how the mechanism would be? I mean how do you
deal with threats detailed in section 4.3.  Third Party Denial-of-Service
Attacks of draft-nordmark-multi6-threats-00.txt.
I think that you meant using a cookie, but i think that you will need to
exchange the cookie using all of the locators of the set, right?
I mean it is not enough to exchange cookie through a single locator, you
need to do it through all locators.

> Even with DNS, the set of locators may still be exchanged, in
> which case, DNS reverse-forward lookup should be used
> to verify the set.
>

Yes, that is noid, i think

> As the entire process is light weighted (unless secure DNS is
> used, which is one of a reason why secure DNS is impractical),
> further attempt of DoS prevention is unreasonable only
> to increases the chance of DoS.
>

The remaining attack AFAICS, is how do you prevent connection hijack from an
attacker that intercept the initial three way handshake and then moves away.
Note that currenlty an attacker can only hijack a connection as long as he
stays in the path intercepting packets, so if you allow this type of attacks
you are introducing a new vulnerability.

BTW: Erik, in a quick scan i haven't seen this attack in the threats draft,
but i guess it should be there, right?

Regards, marcelo

> 						Masataka Ohta
>
>