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

From: Tina TSOU <[email-masked]>
Date: Wed, 6 Mar 2013 19:03:12 +0000

Dear all,
The IPv4 predictable Identification issue is being well discussed and emphasized. This work forces on the IPv6 fragment header predictable identification issue and tries to protect such vulnerable implementations from being suffered from DoS attack, by providing several possible and practicable algorithm to generate random id. From the perspective of implementation, such as NAT, etc., which might aggravate the issue being told, such work is instructive.

Besides, the author added a survey in the latest version which addressed some of the former comments. I technically support this draft.

Thank you,
Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> Sent: 2013年2月28日 11:52
> To: [email-masked] 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-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Mar 2013 10:44:27 +0100

>    (if yes, you must be willing to contribute, if no, then say why)

Yes.

I think the document is very useful. The fact that there are so many 
popular implementations out there that get this kind of thing wrong 
shows a need for good documentation. This draft explains the problem, 
says clearly what needs to be done, and describes good and practical 
algorithms. And there's a survey of current implementations as a bonus 
in the appendix. This is exactly the kind of good quality information 
that the IETF needs to provide.

Simon

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Mar 2013 11:09:55 +0100

Simon,

> I think the document is very useful. The fact that there are so many popular implementations out there that get this kind of thing wrong shows a need for good documentation. This draft explains the problem, says clearly what needs to be done, and describes good and practical algorithms. And there's a survey of current implementations as a bonus in the appendix. This is exactly the kind of good quality information that the IETF needs to provide.

- are you willing to work on the document?
- do you think this should be done in 6man or elsewhere?

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Mar 2013 11:13:47 +0100

Yes.

> - do you think this should be done in 6man or elsewhere?

6man

Simon

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Mar 2013 07:28:24 -0300

Ole,

> - are you willing to work on the document? 

I'm really curious about these questions.

What does "working on a document" mean? For instance, it's probably the
first time I see this question asked when polling the wg for support of
a document.

> - do you think this should be done in 6man or elsewhere?

That aside, this document aims to update RFC 2460. Where else should
that be done, if not in 6man??

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Mar 2013 11:44:08 +0100

> first time I see this question asked when polling the wg for support of

It's common. I understand it to mean reviewing the draft, providing 
comments, etc.

> that be done, if not in 6man??

That's a technicality. What's more important is that the relevant 
expertise is in 6man.

Simon

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Mar 2013 12:02:27 +0100

Simon,

> It's common. I understand it to mean reviewing the draft, providing comments, etc.

yes.

> That's a technicality. What's more important is that the relevant expertise is in 6man.

when this document was presented in 6man at IETF84, there were suggestions that a more generic
document could be written. e.g. in intarea.

I don't want us to end up with an RFC per field per protocol.

there isn't an equivalent document for IPv4, right?

there are other alternatives too, e.g. an errata to 2460, or an update to the nodes requirement document.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Mar 2013 17:13:58 -0300

> document could be written. e.g. in intarea.

We have beaten this one to death -- but you still bring this one up:
Most folks agreed that a general document (in *addition* to this one)
would be useful, but this one would be valuable and *needed*.

You cannot have a general document update RFC 2460. And different fields
have different constraints. I wouldn't objet to such a general document
*in addition* to this one: for the most part, they are orthogonal.

> I don't want us to end up with an RFC per field per protocol.

You seem to have done everything at hand for this document not to
progress. But I would appreciate if it was the working
group deciding on such progress.

Besides, there's no "one RFC per field". Because IIRC, this is the only
such I-D we have in IPv6.

As a data point, the transport area produced RFC 6056 -- and they/we
didn't refrain from publishing an RFC by means of an errata (and please
take a look at such I-D, and see how the contrainst are different).

In a more broader sense, I wonder what's the point of having a
"maintenance" working group when it looks like you seem to do anything
to avoid formally updating existing standards (this is not the first
instance of that).

Man, protocols has flaws, in the same way that code has bugs. When you
find them, you fix them (rather than pretending there's nothing to fix,
opposing to fix them, or fixing them while pretending you aren't).

> there isn't an equivalent document for IPv4, right?

There is not -- In the same way that IPv6 deprecated RHT0, but IPv4
didn't deprecate source routing.

What's the point that you're trying to make? That we should repeat IPv4
history?

Do you really want implementations to keep the flawed scheme,
implementations to come up with their own flawed algorithms, etc.?

Haven't we learned anything from IPv4's history?

> there are other alternatives too, e.g. an errata to 2460, or an update to the nodes requirement document.

That would be incorrect. You cannot have a "node requirements" for
something that is against an existing std.

And if this is an errata, what's a protocol update?

Besides, you'll realize that the document is a bit larger than
one-paragraph long. And there's much more valuable information that
would could put in an errata, or a node requirements update.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Mar 2013 22:16:00 +0100

Fernando,

may I suggest you keep ranting to a minimum.

> would be useful, but this one would be valuable and *needed*.

<chair>
that is not evident from this thread, nor the minutes from IETF84.
</chair>

[...]

> to avoid formally updating existing standards (this is not the first

yes, and I think it is also our responsibility to limit too much tinkering.
in this case fixing what appears to be a marginal problem, in descriptive
text of RFC2460.

[...]

> would could put in an errata, or a node requirements update.

"It is recommended to use unpredictable values in protocol fields"?

the above is good advice, I do not think it necessary to publish a document
to update non-normative text in 2460.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Mar 2013 19:12:59 -0300

> may I suggest you keep ranting to a minimum.

Have you counted how many emails I have sent you off-list regarding this
and other I-Ds? Have you noted how many times I had to ask you simply to
poll the wg about adoption of this document?

> that is not evident from this thread, nor the minutes from IETF84.

Both in this thread on in the minutes, it was basically just the chairs
arguing in favor of an errata. Other folks (such as Lorenzo Colitti)
argued that both a general document *and* this one looked like a good
way forward.

And then there were folks such as Joel Jaeggli, who noted that I might
want to go Informational -- probably because for some folks standards
are written into stone.

So yes, I disagree with you. If you want, I may try to do a transcript
of the relevant meeting (the audio is available, anyway). And the
current thread does not seem to support your "let's do nothing about
this" proposal, either.

> in this case fixing what appears to be a marginal problem, in descriptive

Look:

Two BGP routers talking to each other. Both using predictable I-Ds.
Attacker fires an ICMPv6 PTB to one of them (or both). The starts
sending fragments to their other endpoints. GTSM is of no help here.

Does that look marginal to you?

And the descriptive text has resulted in many vulnerable implementations
-- we do care about running code, right?

Do I really need to publish an automated tool that implements this, and
then include a URL to your note of this "being a marginal problem"?

> to update non-normative text in 2460.

It is necessary when so many implementations got it wrong.

And if you have followed IPv4's history in this respect, you'll realize
that advice *is* needed -- not only in terms of normative language, but
also in terms of proposed algorithms -- unless you want implementations
to work twice on this issue, as many implementations did for IPv4, since
they got it wrong the first time.

Thanks,

---

From: Arturo Servin <[email-masked]>
Date: Fri, 08 Mar 2013 10:58:23 -0200

Hi

On 28/02/2013 17:51, Ole Troan wrote:
> Hi,
> 
> The draft-gont-6man-predictable-fragment-id document has been discussed a few times.

	Yes. Please adopt.

>   (if yes, you must be willing to contribute, if no, then say why)

	Yes, I am willing to review and send comments.

> Ole & Bob

Regards,
as

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 10 Mar 2013 21:54:12 +0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ole Troan
> Sent: Thursday, February 28, 2013 2:52 PM
> Fernando Gont presented the draft about Security Implications of
> Predictable Fragment Identification Values,
> 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.
> 
> 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.

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 10 Mar 2013 23:07:42 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Sunday, March 10, 2013 2:54 PM
To: Ole Troan; [email-masked] 6man-wg
Subject: RE: Next steps for draft-gont-6man-predictable-fragment-id

Ole,

                                               Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ole Troan
> 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.
> 
> 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.
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Mar 2013 10:25:45 +1100

In message <[email-masked]
p.microsoft.com>, Dmitry Anipko writes:
> In such an attack, is the attacker on the path between the victim and the ser
> ver? 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 w
> ith fake source address to that particular victim host)?
> 
> Separately from that, how often network operators deploy egress filtering, th
> at drops packets from malicious hosts sent with fake source addresses?

Well we know enough of them don't for reflection amplicifation attacks
to be a be a problem.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 Mar 2013 22:15:11 -0400

Dimitri,

Please find my responses in-line...

On 03/10/2013 07:07 PM, Dmitry Anipko wrote:
> In such an attack, is the attacker on the path between the victim and
> the server? 

No.

> 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)?

Simple example: Think about the DNS "client" being the catching DNS
server of a large ISP, and the DNS server the authoritative server for a
zone.

> Separately from that, how often network operators deploy egress
> filtering, that drops packets from malicious hosts sent with fake
> source addresses?

This one was answered by Mark Andrews, already.

Thanks,

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 11 Mar 2013 09:17:38 +0200

I believe the doc describes nicely the possible security issues of predictable fragment ids in IPv6.
Although the attack scenarios aren't so common/easy as in IPv4 and various operating systems have fixed most of them, i still find urgent to need to standardize this behavior, now that IPv6 is still not thoroughly exposed to the wild. Thinking some years ahead, the internet of things multiplies the chances of something bad happening due to this.
I'm having a doubt about the title though, because "Security Implications of Predictable Fragment Identification Values" gives the impression of a BCP or informational.

Lastly,  i would also vote for another doc giving general directions for usage of such fields (ids, sequence numbers, ports, etc) in future protocols. It feels strange to meet the same issues again and again.

PS: it would be good to find a way to somehow authenticate/verify ICMPv6 PTB messages; then many fragment-related issues would probably be solved in advance.

--
Tassos

---

From: John Day <[email-masked]>
Date: Sun, 10 Mar 2013 19:53:59 -0400

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.

>filtering, that drops packets from malicious hosts sent with fake 

There are enough shady operators that that isn't a problem.

Anyone who is more devious than I am want to volunteer suggestions?  ;-)

>Of Ronald Bonica
>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:
>
>- 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:
>
>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
>
>

---

From: John Day <[email-masked]>
Date: Mon, 11 Mar 2013 00:30:07 -0400

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.)

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Mar 2013 07:35:39 -0400

Le 2013-03-10 19:53, John Day a écrit :
> It doesn't take long to cycle through sending 65K messages.  You only
> need to send one fragment per identifier.

But we're talking about IPv6, where it's 32 bits.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 11 Mar 2013 12:57:46 +0000

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

> From: John Day [mailto:[email-masked]]
> Sent: Monday, March 11, 2013 12:30 AM
> To: Dmitry Anipko; Ronald Bonica; Ole Troan; [email-masked] 6man-wg
> 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
> >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)?
> >
> Of
> >Ronald Bonica
> >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.
> >
> UDP.
> >Even in the absence of an attack, many of these packets will be
> >fragmented.
> >
> >- 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
> >
> 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:
> >
> >>  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.
> >>
> >> 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.
> >>
> >>  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.
> >>
> >>  IETF IPv6 working group mailing list  [email-masked]  Administrative
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Merike Kaeo <[email-masked]>
Date: Thu, 14 Mar 2013 23:56:51 -0700

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