Subject: TR: [mobile-ip] A new proposal for handling Home Address destination options

From: "Jean-Michel COMBES" <[email-masked]>
Date: Fri, 15 Feb 2002 12:48:50 +0100

Sorry, I forgot to send the reply to the ML

Regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

-----Message d'origine-----
De : Jean-Michel COMBES [mailto:[email-masked]]
Envoye : vendredi 15 fevrier 2002 11:29
A : [email-masked]
Objet : RE: [mobile-ip] A new proposal for handling Home Address
destination options

Hi Charlie,

my first comment is that your proposition doesn't concern all cases.
For me, there are four cases. Explanations :

We assumed that the attacker's packet looks like :
IPv6Src: Attk@
IPv6Dst: Refl@
H@-DO : Vict@
with Attk@ = Attacker's IP address, Refl@ = Relector's IP address and Vict@
= Victim's IP address

What happens then ?

*** Case 1 : Vict@ is in the reflector's BC ***
- the victim is a MN with H@ = Vict@ = MN-H@
- the MN is registered with a Co@ = MN-Co@
The reflector sends a packet looks like :
IPv6Src: Refl@
IPv6Dst: MN-Co@
"RH" : Vict@ = MN-H@

Then two sub-cases :

*** Case 1a : MN location is still MN-Co@ ***
Solution : if the MN is equipped with a personal firewall, then the packet
is rejected.

*** Case 1b : MN location is not MN-Co@ ***
Solution : ???

*** Case 2 : Vict@ is not in the reflector's BC ***
The reflector sends a packet looks like :
IPv6Src: Refl@
IPv6Dst: Vict@

Then two sub-cases :

*** Case 2a : the victim is a MN ***
Solution : your proposition

*** Case 2b : the victim is not a MN ***
Solution : ???

Am I wrong ?

[snip]
>
> In order to make a good design, we must first distinguish between
> a verifiable Home Address options (vHAO), and unverifiable Home
> Address options (UnvHAO).  A vHAO is a home address option that
> contains a care-of address

JMC :
Typo ? You mean a Home Address, do you ?

> that can be matched up to the care-of
> address in a Binding Cache entry for a mobile node's home address.
> UnvHAOss cannot be so verified, typically because the correspondent
> node doesn't have any Binding Cache entry for the mobile node.
> The design team recommendation for the vHAOs is good, and should
> be incorporated into the specification.  For the rest of this
> note, I only consider UnvHAOs.
>
> For UnVCoAs, more care is needed.  We can make some simple
> improvements to the way that correspondent nodes handle UnvHAOs
> that will substantially reduce or eliminate any residual threat
> of a viable reflector attack.  The first weapon in the arsenal
> against these attacks is to tag outgoing packets with the
> unverifiable care-of address.

JMC :
Do you mean that the CN adds a DO (for example) containing Co@ in its packet
? So with today Mobile IPv6 draft, when this is an UnVCoA, the CN MUST
always send replies to MN with a RH (type 0) containing the UnVCo@. Am I
wrong ?

>  These packets will then reach
> the home agent.

JMC :
not always true, only if the victim is a MN (see the cases I explain on the
top of my reply)

> The home agent has to look up its Binding
> Cache entry for the mobile node.  If the care-of address does
> not match the care-of address tagged by the correspondent node,
> then the home agent can begin diagnostics or tracing for a
> possible attacker, and then it would drop such packets.  If the
> care-of address matches, then we are back to good, with much
> better security.  Typically, along with tagging the packet,
> the correspondent node would also take action to establish a
> Binding Cache entry so that the care-of address would become
> verifiable.
>
> The other simple mechanisms which further reduce or eliminate
> vulnerability to the reflector attack are simple rate and
> capacity limitations at the correspondent node.  Any correspondent
> node should only have a limited capacity for such UnvHOAs (perhaps
> 5 or so, but configurable and perhaps larger for big servers).

JMC :
what happens if the attack is distributed (ie. the bad guy sends forged
packets to many reflectors) ?

Regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214