Re: Fwd: Minutes / Notes

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Pekka Nikander;

> > It should also be noted that binding between locators and identifiers
> > in single DNS reply packets have just enough security.
> 
> No, it doesn't, see below.

Yes, it does.

> > The variant (or a simple case) is an issue to be addressed by
> > return routability and/or DNS reverse/forward mapping just as
> > current IPv4 or 6.
> 
> Please get your facts right.
> 
> 1. I create the following DNS records for myself
>     (using A here for AAAA just to make the point...)
> 
>     pnr.iki.fi.         IN IDENTITY XXX
>     pnr.iki.fi.         IN A        131.112.32.132
>     pnr.iki.fi.         IN A         81.17.193.194
> 
>     [For those who don't want to check,
>      81.17.193.194 is pnr.iki.fi,
>      131.112.32.132 is necom830.hpcl.titech.ac.jp]
> 
> 2. I order a large number of streams, all
>     associated with XXX, directed to 81.17.193.194
>     These can be TCP or UDP streams...
> 
> 3. I start sending acknowledgements with source
>     address spoofed to 131.112.32.132
> 
> 4. The hosts shipping the streams think that my
>     link to 81.17.193.194 has just crashed, and
>     start shipping the packets to 131.112.32.132
> 
> The rest should be clear.

Ignoring the mistake that using source address of 131.112.32.132
does not make its peer that 81.17.193.194 has crashed...

Yes, lacking proper acknowledgements from 131.112.32.132, the
peer will terminate the stream.

That is, you can't send proper acknowledgements, unless you can
receive packets to 131.112.32.132, which is the return routability.

It should also be noted that there is no amplificaiton here that
it is no worse than ICMP echo requests with spoofed source addresses.

> Yes, you can defeat
> this particular scenario by saying that in IPv6
> ingress filtering will be universally deployed,
> but there are other, more complex ones where
> ingress filtering does not necessarily help.

Yes, similar attack is, for example, possible with

    pnr.iki.fi.         IN MX        10 pnr.iki.fi,
    pnr.iki.fi.         IN MX        20 necom830.hpcl.titech.ac.jp
    pnr.iki.fi.         IN A         81.17.193.194
    necom830.hpcl.titech.ac.jp IN A        131.112.32.132

and sending a lot of erroneous mails from pnr.iki.fi to
random recipients.

So?

						Masataka Ohta