[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
From: Merike Kaeo <merike () doubleshotsecurity ! com>
Date: 2013-03-15 6:56:51
Message-ID: 01C68838-549E-403E-8142-939ED96BD5AE () doubleshotsecurity ! com
[Download RAW message or body]
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:jeanjour@comcast.net]
> > Sent: Monday, March 11, 2013 12:30 AM
> > To: Dmitry Anipko; Ronald Bonica; Ole Troan; ipv6@ietf.org 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: ipv6-bounces@ietf.org [mailto:ipv6-bounces@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-bounces@ietf.org [mailto:ipv6-bounces@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
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic