Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Mar 2002 16:31:59 +0100 (CET)

> To be completely honest, I do not have data to determine
> whether the vulnerability is completely negligible, or
> only very, very small.  I think that one could guesstimate
> the likelihood of the occurrences that you described, based
> on IP reordering pprobabilities, and it surely is a tiny
> probability.   We have already designed ingress filtering
> techniques that almost completely eliminate any lingering
> abilities for attackers to mount this highly improbable attack.

Charlie,

Are you talking about the ideas about "smart" ingress filtering or something
else here?

As I hope I showed with my examples today's ingress filtering before the CN
can't do anything since it will just inspect the IP source address which
the attacker does not need to spoof.

And filtering after the CN can't tell the difference between the good and
bad packets since the tags assigned to the packets can be quite random
when the CN receives multiple HAO values for the same HoA.

  Erik

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Mar 2002 07:17:30 -0500

Erik,

Come on I don't think your being "fair" we both ship web servers that
deal with 10 million hits in a very short time any CN that is supporting
serious Mobile IPv6 is not going to run into this caching problem as the
norm.  Thats an absurd and sophist argument philosophically (Plato's
sophism).  It is not a technical argument but a technical assumption.  I
don't agree with either.  Also the servers that do OLTP is even more
intense than the web server case.

/jim

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, March 11, 2002 4:39 AM
> To: Jari T. Malinen
> Cc: [email-masked]; Charles E. Perkins; Erik Nordmark;
> Rajeev Koodli
> Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing -
> Recommendation note
> 
> 
> Jari,
> 
> > - On robustness: both verified and unverified caches are in reality
> >   finite in size. Both would have a similar error mechanism
> >   anyway so there is hardly a difference in robustness in
> >   RO-BC or unverified cache filling up. With the latter you
> >   may lose some packets in transit, but also with the former,
> >   it is just a cache and may get destroyed before or without
> >   new BU reaching the CN. In a worst case a RO data packet may
> >   be on path and get dropped in such a gap. This should not
> >   be a real argument.
> 
> The above should not be a real argument :-) :-)
> 
> Seriously,
> I think there is a big difference between the case when the CN reboots
> and losses all state (including transport and application 
> state) i.e. looses
> the BCE state compared to the unvHAO idea of effectively
> doing "send and prey" that an unvHAO entry can be created on the CN.
> 
>    Erik
> 
>