Re: comments on nordmark-multi-threats

[Erik Nordmark <Erik.Nordmark@sun.com>]

Pekka,

Thanks for your comments.

> One thing the doc could maybe be slightly clearer on is which "security
> problems" the different attacks rely on (e.g., off-link TCP ACK spoofing,
> TCP seq number synchronization (could be very challenging if tryly random
> seq/ack numbers are used, etc.)

We can try to add this.

> A couple of observations and minor nits below, nothing major.
> 
>    Similarly, if DNS can be compromised, and a change can be made to an
>    advertised resource record to advertise a different IP address for a
>    hostname, effectively taking over that hostname.
> 
> ==> does this imply DNS threats, in addition to just hacking thezone?

I don't know what "hacking the zone" means.
A DNS lookup, without DNSsec, can be spoofed if the
attacker can spoof the source address, match a (16 bit, probably predictable)
number in the query, and guess the domain name that was in the query.
 
>    Any system that is along the path from the source to the destination
>    host can be compromised and used to redirect traffic.  Systems may be
>    added to the best path to accomplish this.  Further, even systems
>    that are on multi-access links that do not provide security can also
>    be used to redirect traffic off of the normal path.  For example, ARP
>    and ND spoofing can be used to attract all traffic for the legitimate
>    next hop across an Ethernet.
> 
> ==> these apply to DNS the paths and links to the DNS server as well, of 
> course.

Yes, until DNSsec gets deployed.

> 
>    An attribute of this type of attack is that A will simply think that
>    B is faulty since its flow and congestion control mechanisms don't
>    seem to be working.  Detecting that the stream of ACK packets is
>    generated from X and not from A might be challenging, since the rate
>    of ACK packets might be relatively low.  This type of attack might  
>    not be common today because it requires that X remain on the path in
>    order to sustain the DoS attack, but the addition of multihoming
>    redirection mechanisms might potentially remove that constraint.
> 
> ==> it is not readily apparent why X would need to remain on the path to 
> continue this, but I didn't think this through.  Maybe need spelling out?

Should spell that out. Its ability to move off the path is constrained
by whatever amount of ingress filtering is used.

> fully editorial
> ---------------

Thanks - taken care of.

>    multihoming solution would fail our "no worse than what we have now"
>    litmus test.  However, given that ingress filtering deployment is far
> 
> ==> "litmus test" ?

Originally paper used to test the pH of a solution.
Used a lot more generally; google it for examples of broad usage.

  Erik