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

[Merike Kaeo <[e-mail]>]

Fernando asked me to review this document and while I haven't been active in 6man (lurking mostly in past years) I've now spent time reviewing history of all comments and read draft.  

My take is the following:

- many RFCs exist where some mention is made on using non-predicatable values in some sense (RFC5452 section 9.2 on unpredictable src ports, RFC6528 which describes random seq numbers and I'm sure there's others).....I don't know of an overarching document that discusses using unpredictable numbers in the general sense.

- This document addresses a specific security concern which can be exploited as Ron describes.  Since the non predictability has been found to exist in at least a few current implementations...I am left wondering what tablet and phone OSs do.... it is a current issue in more than one OS so I feel this issue deserves to be called out (and due to precedent set in previous other documents I feel it's OK to just have it be published without forcing it to be incorporated into a more general document)  

More people are ramping up with IPv6 implementations....some IPv4 lessons will not be known to newer engineers and implementors.  So again, I think a document that simply points to the issue here for IPv6 is OK.

I'd support it in that I would offer some additional review and comments.

And lastly, I concur with Ron to definitively state that source address validation is not as widely utilized as needed.....there's a new wave of focus on it which is largely due to the DNS amplification attacks that resurfaced within the last year (but focus doesn't mean people will configure) :(

- merike


On Mar 11, 2013, at 5:57 AM, Ronald Bonica wrote:

> Dmitry,
> 
> The attacker does not need to be on the path between the victim and the Name Server.
> 
> Furthermore, the attacker doesn't need to know:
> 
> - which hosts (other than the victim) might communicate with the Name Server
> - when the victim might communicate with the Name Server
> 
> Recall that the target of the attack is the victim, and the victim only. The attack is not directed towards Name Server or its other clients. Also recall that the goal of the attack is to make it impossible for the victim to reassemble fragmented packets from the name server. The attacker can do this by sending a small continuous stream of packet to the victim with the following characteristics:
> 
> - spoofed source address (that of the Name Server)
> - a fragment-ID that it being used by the Name Server at the same time
> 
> Because the stream is relatively small, it is not likely to be detected, even if it persists for hours. So, the attacker can start the stream and wait for the victim to attempt to communicate with the Name Server.
> 
> You are correct in saying that this wouldn't be a problem if all networks validated source addresses. Sadly, source address validation is not nearly so common as it should be.
> 
>                                                Ron
> 
> 
>> -----Original Message-----
>> From: John Day [mailto:[e-mail]]
>> Sent: Monday, March 11, 2013 12:30 AM
>> To: Dmitry Anipko; Ronald Bonica; Ole Troan; [e-mail] 6man-wg
>> Subject: RE: Next steps for draft-gont-6man-predictable-fragment-id
>> 
>> 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: [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
>>> --------------------------------------------------------------------
>> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------