A second thought.
Really all you have to do is grab some cloud resources and you can
blast away at thousands of people starting at hundreds of points in
the identifier space and since you have already hacked the cloud, it
is all free.
(After the RSA breach (I had students involved in the clean up), it
was pretty clear that the probability that all data centers had been
compromised was pretty close to 1.)
At 11:07 PM +0000 3/10/13, Dmitry Anipko wrote:
In such an attack, is the attacker on the path between the victim
and the server? If yes, there are more efficient ways how they can
DoS the victim. If no, how does the attacker know which of the
billions hosts on the Internet will be talking to this DNS server in
the next second (in order to send packets with fake source address
to that particular victim host)?
Separately from that, how often network operators deploy egress
filtering, that drops packets from malicious hosts sent with fake
source addresses?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Ronald Bonica
Sent: Sunday, March 10, 2013 2:54 PM
To: Ole Troan; [email protected] 6man-wg
Subject: RE: Next steps for draft-gont-6man-predictable-fragment-id
Ole,
There may exist at least one attack scenario that is sufficiently
serious to motivate this work. I will describe the scenario and
invite DNSSEC and security types to correct me if I have it all
wrong.
Name Servers running DNSSEC frequently send very long packets over
UDP. Even in the absence of an attack, many of these packets will be
fragmented.
Now assume an attack scenario in which the victim is a legitimate
client of that Name Server. An attacker seeks to prevent the victim
from receiving fragmented packets from the Name Server. In order to
achieve that goal, the attacker:
- determines the range of fragment-ids that the Name Server is
likely to emit in the next second or so
- sends a stream of packets to the victim, spoofing the Name
Server's address and using each member of the fragment-ID range
- repeat periodically
The attacker will prevent a legitimate packet from the Name Server
from being reassembled if he delivers a packet with the correct
fragment-id to the victim between the time that the victim receives
the first and last fragments of the legitimate packet. The attacker
may not be able to corrupt every fragmented packet from the Name
Server to the victim, but his chances of success improve as:
- the range of fragment-ids that the Name Server is likely to emit decreases
- the time between the arrival of the first and last fragments of
the legitimate packets increases
In any event, since DNSSEC contributes significantly to the security
posture of the Internet, we should probably address the issue of
predictable fragment-IDs.
Ron
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Ole Troan
Sent: Thursday, February 28, 2013 2:52 PM
To: [email protected] 6man-wg
Subject: Next steps for draft-gont-6man-predictable-fragment-id
Hi,
The draft-gont-6man-predictable-fragment-id document has been
discussed a few times.
At the IETF84 (minutes attached below), and in the thread:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15836.html
Could we get the working groups opinion on what to do with the
document?
- Is there interest in working on it in 6man?
(if yes, you must be willing to contribute, if no, then say why)
Best regards,
Ole & Bob
IETF84 minutes:
============
Fernando Gont presented the draft about Security Implications of
Predictable Fragment Identification Values,
(draft-gont-6man-predictable-fragment-id-02.txt)
Ole Troan wanted to make this document more generic and discuss the
> implications of using predictable values in Internet protocols.
Fernando
Bob Hinden wanted to see a longer list of OSs. He was also curious as
to whether this was problem that needed to be fixed in IETF or was
this already common knowledge.
Erik Kline wanted to know if there was an IAB document that
recommended the use of non-predictable values if there was an integer
field that did not need specific values.
Thomas Narten was not sure what to do with this. This fell under the
category of "don't do anything stupid". e.g. Why do a document for
IPv6 for things that were well known in IPv4?
Lorenzo Colitti thought that this work was not harmful and should be
pursued irrespective of any iab work.
Brian Haberman did not want to have a point solution for every field
and he would like to see a more general document applicable across the
IETF. Fernando was concerned on whether implementers would read this
generic document. Brian believed that this generic document could be
referred to in the node requirements document, thus ensuring that IPv6
implementers would read it.
Joel Jaeggli thought that it was a worthwhile activity to look at
existing implementations and flag this as a potential issue that was
common across multiple implementations. Thomas Narten and Erik Kline
agreed with Joel.
Dave mentioned that RFC4732 (Internet DOS considerations) talked about
using unpredictable values for session ids. Fernando talked about
other issues discovered after 4732 that still had this issue. Dave
believed that this sort of work needs to be done by the saag and if
this was included in a statement from saag as something to look for in
SecDir reviews, it would have the largest impact.
Chairs wanted to continue discussion on mailing list and requested
Fernando to discuss potential changes with Joel J.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
