[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on nordmark-multi-threats
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
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.