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

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 07:52:54 -0800

Hello Jean-Michel,

Jean-Michel COMBES wrote:

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

It took me a while to figure out that BC == "Binding Cache"...

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

In this case, there is absolutely no problem.  Since the mobile node
has an entry in the correspondent node's Binding Cache, then the
mobile node has established that Binding Cache entry by some means
that supplied the care-of address for that Binding Cache entry.
If the care-of address does not match what's in the Home Address
Option, then the packet is dropped.  This is the "verifiable" case
in my proposal, and as I indicated in my note, this is to follow the
recommendation of the design team -- namely, if the are Binding
Cache entries for the home address, and none of them match the
care-of address sent in the Home Address option, the packet is
dropped (perhaps also logged for security).

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

In case 2b, the firewall should drop packets destined for a network
that does not have mobile nodes, but that have the care-of address tag.
I did mention this in my proposal.

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

No, but I still didn't say what I meant.  I meant that the vHAO is a home
address option in a packet which contains a care-of address which is
verifiably associated with the mobile node's home address.

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

The format of the tag is not decided.  It could be a routing header with
segments-left == 0.  It could be something else.  The format of the tag
might depend on the outcome of the ongoing discussion about what kind
of routing header should be used for route optimization.

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

Then the bad guy has done exactly the same thing, but less efficiently,
than sending all the packets itself to the victim.  It would be faster for
the bad guy to just forget about this useless method of attack.  Plus the
attack is eminently traceable.

I do not think this remaining threat is at all worthy of amputating useful
protocol functionality.

Regards,
Charlie P.

---

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

Charlie,

> -----Message d'origine-----
> De : Charlie Perkins [mailto:[email-masked]]
> Envoye : vendredi 15 fevrier 2002 16:53
> A : COMBES jean-michel FTRD/DTL
> Cc : Mobile IP Working Group
> Objet : Re: [mobile-ip] A new proposal for handling Home Address
> destination options
>
>
>

[snip]

> It took me a while to figure out that BC == "Binding Cache"...

JMC : sorry ...

> dropped (perhaps also logged for security).

JMC :
And what happens in the case where the CN has not received the new MN
location (ie. the new MN-Co@) ?

> verifiably associated with the mobile node's home address.

JMC :
OK ... I see now :-)

[snip]

> attack is eminently traceable.

JMC :
I meant what happens when the bad guy sends forged packets to many
reflectors to attack the same victim ? Example :
IPv6Src: Attk@, IPv6Dst: Refl@#1, H@-DO : Vict@
IPv6Src: Attk@, IPv6Dst: Refl@#2, H@-DO : Vict@
IPv6Src: Attk@, IPv6Dst: Refl@#3, H@-DO : Vict@
...
IPv6Src: Attk@, IPv6Dst: Refl@#n, H@-DO : Vict@

with Refl@#1 the address of the reflector host #1, Refl@#2 the address of
the reflector host #2, etc.

> I do not think this remaining threat is at all worthy of amputating useful

Thanks for your comments.

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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 19:15:29 +0100

=> the obvious attack is to create a wrong entry in the UnvHAO cache
so no drastic action like to drop a packet should be required on
a bad tag.

   segments-left == 0.

=> I really like the HAO with a RH-like segment-left field.

   
=> I agree: there are different levels of attacks...

=> this is the apparent security/performance lost tradeoff...

Thanks

[email-masked]