RE: Next steps for draft-gont-6man-predictable-fragment-id

[John Day <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Ronald Bonica
>Sent: Sunday, March 10, 2013 2:54 PM
>To: Ole Troan; [e-mail] 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: [e-mail] [mailto:[e-mail]] On Behalf
>>  Of Ole Troan
>>  Sent: Thursday, February 28, 2013 2:52 PM
>>  To: [e-mail] 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
>>  [e-mail]
>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>  --------------------------------------------------------------------
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[e-mail]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[e-mail]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------