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)?
Better to ask Fernando, but let me take cut at it.
First of all, you pick your target. This isn't a random act. If you
want to attack someone, you probably have someone in mind. If that
someone happens to be a relatively heavy web user (or almost anything
else) and/or you take the time to study their habits, it wouldn't be
hard. You are hitting DNS fairly often. Why pick one point in the
identifier space? Pick several. It doesn't take long to cycle
through sending 65K messages. You only need to send one fragment per
identifier.
Separately from that, how often network operators deploy egress
filtering, that drops packets from malicious hosts sent with fake
source addresses?
There are enough shady operators that that isn't a problem.
Anyone who is more devious than I am want to volunteer suggestions? ;-)
-----Original Message-----
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of Ronald Bonica
Sent: Sunday, March 10, 2013 2:54 PM
To: Ole Troan; ipv6@ietf.org 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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of Ole Troan
Sent: Thursday, February 28, 2013 2:52 PM
To: ipv6@ietf.org 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
