> > I don't think that the reason that EBU just limits
> > the attack to a very small amount of time is good
> > enough as the attacker just have to send a lot more
> > EBUs for it to increase the magnitude.
>
>
> Hi Mohan,
>
> I agree that solely limiting the time during which data packets can be sent
> to an unverified care-of address - i.e., a care-of
address for which a care-of-address test has not yet been accomplished - is
insufficient to prevent flooding attacks. For this
reason, Early Binding Updates apply a mechanism, Credit-Based Authorization, to
ensure that the data volume sent to a mobile node at
an unverified care-of address is limited by the effort which the mobile node
has recently spent while its care-of address was
verified.
>
> I gave a presentation of Credit-Based Authorization during the
> MOBOPTS-Session of the 59th IETF meeting. The mechanism will be
detailed in the next version of the Internet-Draft on Early Binding Updates.
>
Ok. By limiting the amount of data sent during the "unverified care-of-address"
window, you
still want it to be useful for applications that wanted to use EBU. Not knowing
the details, i will
wait for your next version of the draft.
-mohan
> Kind regards,
>
>
> - Christian
>
>
> |
> | Christian Vogt
> | Institute of Telematics, University of Karlsruhe (TH)
> | www.tm.uka.de/~chvogt/
> |
>
>
> Mohan Parthasarathy wrote:
> > Francis,
> >
> > I am trying to understand your argument better..
> >
> >> In your previous mail you wrote:
> >>
> >> But what we in my opinion
> >> should prevent is the amplification, not pure reflection.
> >>
> >> => this is the detail we disagree: if we prevent pure reflection,
> >> we prevent this attack and all others using the same hole but
> >> which are *reality*, not speculations.
> >>
> >> I mean if you have ingress filtering,
> >>
> >> => this is the only case which makes sense.
> >>
> >> you might not even
> >> be able to send the EBU to begin with, let alone spoofed ACKs.
> >>
> >> However, we are in part trying to build these things so that the
> >> lack of ingress filtering doesn't open up the situation for many
> >> new attacks.
> >>
> >> => it doesn't matter to get new attacks, it does matter to get no new
> >> attacks which have a definitive advantage over current attacks, e.g.
> >> which defeat ingress filtering by hiding the source address...
> >>
> > I can see your point. Your point is about why would anyone use MIPv6
> > when
> > one can use plain IPv6 to launch the reflection attack. Using MIPv6
> > also has
> > a dis-advantage that it exposes the home address of the attacker. But
> > does it mean that we can design protocols with this vulnerability
> > expecting that ingress filtering will get deployed in the future
> > which will automatically solve this problem ? Then why do we have to
> > CoTI/CoT messages at all in
> > the base protocol ? Assume we ban the alternate care-of-address
> > option,
> > and also that ingress filtering will get deployed in the future, does
> > that mean CoT/CoTI is not needed at all ? I don't think that the
> > reason that
> > EBU just limits the attack to a very small amount of time is good
> > enough as the attacker just have to send a lot more EBUs for it to
> > increase the magnitude.
> >
> > -mohan
>
> 2*zT¨¥Sx%SËLSz¢z×è®m¶>?ÿ 0?ë_¢¸?T¨¥T©ÿ-+-Swèþh©
|
