Subject: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

From: Ole Troan <[email-masked]>
Date: Thu, 4 Dec 2014 09:07:18 +0100

This message starts a two week 6MAN Working Group Last Call on advancing:

     Title           : Security Implications of Predictable Fragment Identification Values
     Authors     : Fernando Gont
     Filename   : draft-ietf-6man-predictable-fragment-id-01.txt
     Pages        : 16
     Date           : 2014-04-30

      http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id-01

as a Best Current Practice Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on December 18, 2014.

Note: While the document has expired, we didn't consider it necessary to refresh it purely for the sake of initiating the working group last call.

Regards,

Bob Hinden & Ole Trøan

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 5 Dec 2014 20:09:04 +0000

Folks,

In general, I support the concept, but have a procedural question:

1) Can a BCP UPDATE a Standards Track document?
2) If not, we have two options. These are 
	a) publish this draft as PS
                b) publish this draft as BCP and change the text in Section 4 to be more of a recommendation than an UPDATE to RFC 2460 with a MUST statement.

Personally, I think that the latter is more palatable. If we did the former, many existing IPv6 implementations would become non-compliant with the IPv6 standard. If we did the latter, many existing IPv6 implementations would be non-compliant with the BCP, while remaining compliant with the IPv6 standard.

                                                                                                              Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Thursday, December 04, 2014 3:07 AM
> To: 6man WG
> Cc: 6man Chairs
> Subject: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
> 
> as a Best Current Practice Document.  Substantive comments and statements
> of support for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will end on
> December 18, 2014.
> 
> Note: While the document has expired, we didn't consider it necessary to
> refresh it purely for the sake of initiating the working group last call.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Mon, 08 Dec 2014 10:15:59 -0500

Actually, this document should not be a BCP at all.  This document does
two things:

1. Updates 2460 to not use predictable IDs

2. Provides implementation guidance on generating those fragment IDs.

Both of the above should be done in standards track documents.  I would
suggest changing the draft from BCP to PS.

Regards,
Brian

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 8 Dec 2014 16:58:52 +0000

wfm

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Monday, December 08, 2014 10:16 AM
> To: [email-masked]
> Subject: Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
> 
> Actually, this document should not be a BCP at all.  This document does two
> things:
> 
> >                 b) publish this draft as BCP and change the text in Section 4 to be
> more of a recommendation than an UPDATE to RFC 2460 with a MUST
> statement.
> >
> > Personally, I think that the latter is more palatable. If we did the former,
> many existing IPv6 implementations would become non-compliant with the
> IPv6 standard. If we did the latter, many existing IPv6 implementations
> would be non-compliant with the BCP, while remaining compliant with the
> IPv6 standard.
> >
> >
> > Ron
> >
> >> Subject: 6MAN WG Last Call:
> >> draft-ietf-6man-predictable-fragment-id-01
> >>
> >> as a Best Current Practice Document.  Substantive comments and
> >> statements of support for publishing this document should be directed to
> the mailing list.
> >> Editorial suggestions can be sent to the authors.  This last call
> >> will end on December 18, 2014.
> >>
> >> Note: While the document has expired, we didn't consider it necessary
> >> to refresh it purely for the sake of initiating the working group last call.
> >>
> >> Regards,
> >>
> >> Bob Hinden & Ole Trøan

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Dec 2014 19:16:25 +0100

<nohat>

let me offer a contrarian view.
I don't think we should publish this document. why? because I don't think it is worth the effort required by the community. I think we've pushed the needle too far in publishing 'micro updates'.

RFC2460 does not have normative language in how the Identification value should be generated. therefore I see no need to update RFC2460.

I think the advice may be useful, I'd be happy to see it in an RFC2460 update, or an update to the IPv6 Node requirement document. or more generally you could see a document in intarea titled "IP protocol fields must not be predictable.".

in any case I don't think publishing this particular document as an RFC is good use of our time.

</nohat>

cheers,
Ole

> On 04 Dec 2014, at 9:07 , Ole Troan <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 8 Dec 2014 13:40:10 -0800

At Thu, 4 Dec 2014 09:07:18 +0100,

> as a Best Current Practice Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the a…

I wouldn't be opposed to publishing this document; it certainly
contains useful information and I've not found anything obviously
wrong.  But I also think Ole made some valid point.  If I were to
choose, I'm a bit inclined to NOT publish it as a separate document at
this time. (But, again, if many others want to see it published, I
have no problem with it either).

I have some comments on the latest versions of the draft, all pretty
minor and mostly editorial:

- Abstract: s/simple a/a smple/

   Address.  Some implementations use simple a global counter for

- Section 3: s/the the/the/
   learn the the Identification value currently in use by Host A,

- Section 3: s/ICCPMv6/ICMPv6/
   response (e.g., an ICCPMv6 echo request with a large payload).  The

- Section 4:

   The Identification value of the Fragment Header MUST NOT be
   predictable by an off-path attacker.

  'MUST NOT be predictable' sounds vague to me, especially with the
  RFC2119 keyword.  I'm not sure if there's a precedent of the use of
  this word with a normative keyword, but even if there's, I would
  personally still like to see a clearer term here.  (If, of course,
  we'd like to publish it as an RFC in the end).

- Section 6.3:
   secret1:
      Secret data unknown to the attacker
  (The latter one: this should be "secret2")

- Section 10.1: Not a big deal, but I'm not sure why this has to be a
  "normative reference".

   [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
              6946, May 2013.

--
JINMEI, Tatuya

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 9 Dec 2014 00:14:35 +0000 (UTC)

----- Original Message -----
> From: Brian Haberman <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Tuesday, 9 December 2014, 2:15
> Actually, this document should not be a BCP at all. 

I was thinking that there are a number of RFCs/drafts recommending unpredictable or less predictable field values, with probably more coming because of RFC7258, "Pervasive Monitoring Is an Attack" (I think I've come across two different drafts recommending similar for DHCPv6 field values). So perhaps there should be a more general IAB BCP advising that "Initial and Ongoing Field Values Should Be Unpredictable By Default".

More specific ones such as this would then be PS.

> This document does
>>                  b) publish this draft as BCP and change the text in Section 
> 4 to be more of a recommendation than an UPDATE to RFC 2460 with a MUST 
> statement.
>> 
>>  Personally, I think that the latter is more palatable. If we did the 
> former, many existing IPv6 implementations would become non-compliant with the 
> IPv6 standard. If we did the latter, many existing IPv6 implementations would be 
> non-compliant with the BCP, while remaining compliant with the IPv6 standard.
>> 
>>                                                                             
>                                    Ron
>> 
>>>       Title           : Security Implications of Predictable Fragment 
> Identification
>>>  Values
>>>       Authors     : Fernando Gont
> statements

---

From: Brian Haberman <[email-masked]>
Date: Mon, 8 Dec 2014 21:48:34 -0500

> On Dec 8, 2014, at 7:14 PM, Mark ZZZ Smith <[email-masked]> wrote:
> 
> 
> 
> 
> 

I had asked for such a document when I saw a similar draft discussing the TCP sequence number.

Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 05:29:21 -0300

Hi, Ole,

On 12/08/2014 03:16 PM, Ole Troan wrote:
> <nohat>
> 
> let me offer a contrarian view. I don't think we should publish this 
> document. why? because I don't think it is worth the effort required 
> by the community. I think we've pushed the needle too far in 
> publishing 'micro updates'.

FWIW, this document does three things:

* Requiring that the IP ID be unpredictable
* Providing guidance to achieve that
* Document the implications of predictable fragment IDs

At this point, I'd argue that most of the work has been done --
including getting reviews from folks from other communities that have
been dealing with issues associated with predictable IDs for a long time.

> RFC2460 does not have normative language in how the Identification 
> value should be generated. therefore I see no need to update 
> RFC2460.

That's, actually, one of the reasons for publishing it. The implications
of predictable fragment IDs are, as you'll note in the document itself,
non-trivial.

Similar work has happened elsewhere for other protocols. For example,
RFC6056 for port number randomization or RFC6528 (originally RFC1948)
for TCP sequence numbers.

The price of not doing what needs to be done can be seen in the DNS
spoofing attacks that got widely publicized years ago.

Despite, our previous IPv4 experience, we still have IPv6 stacks
employing predictable fragment IDs. This document has already helped a
few implementations change their IPv6 ID generators, and having a proper
requirement will help to avoid the pain -- which tends to result in way
more effort and damage than getting a document published.

> I think the advice may be useful, I'd be happy to see it in an
> RFC2460 update, or an update to the IPv6 Node requirement document.
> or more generally you could see a document in intarea titled "IP
> protocol fields must not be predictable.".

While I will not rehash this discussion (which we did had at the time),
I should note that !alternative paths" were suggested for
<http://tools.ietf.org/id/draft-gont-6man-slaac-dns-config-issues-00.txt> too,
and we haven't achieved anything in that area. IN this particular case,
there's a concrete an mature document that probably just need a few more
looks and a bit of polishing.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 06:22:49 -0300

Hi, Jinmei,

On 12/08/2014 06:40 PM, 神明達哉 wrote:
>   personally still like to see a clearer term here.

FWIW, RFC6056 (port randomization) says:

   Ephemeral port selection algorithms SHOULD obfuscate the selection of
   their ephemeral ports, since this helps to mitigate a number of
   attacks that depend on the attacker's ability to guess or know the
   five-tuple that identifies the transport-protocol instance to be
   attacked.

OTOH, RFC6528 (TCP SEQ randomization) says:

   F() MUST NOT be computable from
   the outside, or an attacker could still guess at sequence numbers
   from the ISN used for some other connection.

where F() is essentially the TCP SEQ generator..

>   (The latter one: this should be "secret2")

Good grief! -- Will do.

>    [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC

FWIW, the rationale for including it as a normative reference (rather
than in order to understand the attack description in Section 3 (pages
5-6), you need to read RFC6946.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian Haberman <[email-masked]>
Date: Tue, 09 Dec 2014 09:55:11 -0500

On 12/8/14 9:48 PM, Brian Haberman wrote:
>>> From: Brian Haberman <[email-masked]> To:
>>> [email-masked] Cc: Sent: Tuesday, 9 December 2014, 2:15 Subject:
>>> Re: 6MAN WG Last Call:
>> I was thinking that there are a number of RFCs/drafts recommending
>> unpredictable or less predictable field values, with probably more
>> coming because of RFC7258, "Pervasive Monitoring Is an Attack" (I
>> think I've come across two different drafts recommending similar
>> for DHCPv6 field values). So perhaps there should be a more general
>> IAB BCP advising that "Initial and Ongoing Field Values Should Be
>> Unpredictable By Default".
> 

To clarify...

There are several fields in various headers that have the same type of
characteristic (e.g., should be randomly initialized).  A single
document should have been developed to discuss them all together rather
than per-field ST documents.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 09 Dec 2014 09:58:48 -0500

Fernando,

> * Requiring that the IP ID be unpredictable

Let's suppose that the WG decides to publish this document and makes the
above a MUST.

When the WG decides to advance this PS RFC to IS, how do we determine if
this critical component is implemented and interoperable?

Regards,
Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Dec 2014 09:23:43 -0800

At Tue, 09 Dec 2014 06:22:49 -0300,

> where F() is essentially the TCP SEQ generator..

By referring to these, do you mean you think the current text of the
draft is good enough? (asking simply because I'm not sure about the
intent).

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 Dec 2014 19:43:56 +0200

Brian,

> this critical component is implemented and interoperable?

I think that is a good point.  The text is just saying do a good job setting the field.

Personally, I would happier with this draft if it left out the update text and limited itself to recommendations on setting the field.  

Bob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 14:55:22 -0300

On 12/09/2014 11:58 AM, Brian Haberman wrote:
> Let's suppose that the WG decides to publish this document and
> makes the above a MUST.
> 
> When the WG decides to advance this PS RFC to IS, how do we
> determine if this critical component is implemented and
> interoperable?

(Me thinking out loud):

1) In the same way we do for RFC6528 or RFC6056

2) With something similar to
(<http://www.si6networks.com/tools/ipv6toolkit>):

# frag6 -d TARGET --frag-id-poliy

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 14:56:58 -0300

> draft is good enough? (asking simply because I'm not sure about the

No. I'm just noting how it was specified in other cases, to check if you
like those options better (FWIW, when you raised the issue, I wondered
myself "how did we specify this for...?")

Thanks,

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Dec 2014 07:36:22 -0500

> # frag6 -d TARGET --frag-id-poliy

That didn't answer the question.  In order to advance something on the
standards track, there needs to be at least two interoperable
implementations.  How an implementation initializes a field like the
fragment ID, TCP sequence number, or ephemeral port number has no affect
on interoperability.

What you are describing in those documents is implementation guidance,
not a protocol specification.  Given that, I would suggest that this
document strike any normative text, drop the Updates tag, and move to
Informational.

Regards,
Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 10 Dec 2014 14:59:51 +0200

> document strike any normative text, drop the Updates tag, and move to

That is my view as well.

Bob

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Dec 2014 10:53:08 -0800

At Tue, 09 Dec 2014 14:56:58 -0300,

> >> FWIW, RFC6056 (port randomization) says:
[...]
> >> OTOH, RFC6528 (TCP SEQ randomization) says:
[...]
> myself "how did we specify this for...?")

These existing ones look equally vague to me, but I don't have any
good specific suggestion.  Maybe just removing the RFC2119 is the most
realistic choice, just as suggested in other messages of this thread
(for a different, but possibly related) reason.

--
JINMEI, Tatuya

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 18 Dec 2014 01:24:14 +0000

After reviewing this draft and reading the discussions here, I would say support of the publication.

Some comments:
in section 6.2, "   Identification = random()" should be centered.

You may want to remove appendix A, as RFC6946 has been around for a while now. However, I am ok with keeping it.

Regards,
Will

> Sent: Thursday, December 04, 2014 4:07 PM
> To: 6man WG
> Cc: 6man Chairs
> Identification Values
> statements of support for publishing this document should be directed to the
> mailing list.  Editorial suggestions can be sent to the authors.  This last call

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 19 Dec 2014 08:24:19 +0000

Hello,
I reviewed this draft and I support the publication however I have two comments:

1- To avoid problem with current implementations or compatibility, I would suggest to change "Must in section 4 to less strong words like "SHOULD" or "RECOMMENDED".  I can either agree or disagree with people who suggested to have it as informational document. But it appears it gives more information about some attacks rather than a big change on protocol.

2- There are lot of typos in this document such as double "the", ICCMPV6, etc.

Thanks,
Best,
Hosnieh

> Sent: Thursday, December 04, 2014 9:07 AM
> To: 6man WG
> Cc: 6man Chairs
> statements of support for publishing this document should be directed
> to the mailing list.  Editorial suggestions can be sent to the authors.
> This last call will end on December 18, 2014.
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Dec 2014 05:21:52 -0300

Hi, Brian,

On 12/10/2014 09:36 AM, Brian Haberman wrote:
> That didn't answer the question.  In order to advance something on
> the standards track, there needs to be at least two interoperable 
> implementations.  How an implementation initializes a field like
> the fragment ID, TCP sequence number, or ephemeral port number has
> no affect on interoperability.
> 
> What you are describing in those documents is implementation
> guidance, not a protocol specification.  Given that, I would
> suggest that this document strike any normative text, drop the
> Updates tag, and move to Informational.

I personally have no issues with proceeding as indicated.

That said, I'm not sure I follow what you say above. This document has
a requirement that the IP ID must not be predictable, and
implementation advice on how to achieve that. The current status of
the ID is std track for the former, not for the later. As far as this
document is concerned, RFC2460 could already be advanced on the
stndards track, since there are at least four different and
interoperable implementations: FreeBSD, OpenBSD, Linux, and OpenSolaris.

While the (un)predicatability of the IP ID certainly does not affect
interoperability, I guess the same applies to lots of other specs
related to security (for instance, the choice of accepting a
non-authenticated packet/chunk_of_data when authentication mechanisms
are place probably does not affect interoperability.... yet we have
plenty of these (for obvious reasons) in the corresponding specs).

That said, and as noted above, I have no issues with proceeding as you
suggested if that's deemed as the right way to go.

Thanks!

Cheers,

---

From: Brian Haberman <[email-masked]>
Date: Fri, 19 Dec 2014 07:52:29 -0500

> I personally have no issues with proceeding as indicated.

Ok.

> a requirement that the IP ID must not be predictable, and

How does one determine a value is not predictable?  How would the
predictability of the IP ID value affect interoperability?

Nothing that I see in this document impacts interoperability.

> plenty of these (for obvious reasons) in the corresponding specs).

I think you are conflating issues here.  Authentication requires both
ends to use the same mechanism (hence the need for interoperability
since there are multiple authentication mechanisms).

> suggested if that's deemed as the right way to go.

The WG needs to decide which way to go.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Dec 2014 13:45:50 -0300

On 12/19/2014 09:52 AM, Brian Haberman wrote:
>> That said, I'm not sure I follow what you say above. This
>> document has a requirement that the IP ID must not be
>> predictable, and
> 

So... does that mean that the only kind of requirements that we can
issue in protocol specs are those that affect interoperability?

>> implementation advice on how to achieve that. The current status
>> of the ID is std track for the former, not for the later. As far
>> as this document is concerned, RFC2460 could already be advanced
>> on the stndards track, since there are at least four different
>> and interoperable implementations: FreeBSD, OpenBSD, Linux, and
>> OpenSolaris.
>> 
>> While the (un)predicatability of the IP ID certainly does not
>> affect interoperability, I guess the same applies to lots of
>> other specs related to security (for instance, the choice of
>> accepting a non-authenticated packet/chunk_of_data when
>> authentication mechanisms are place probably does not affect
>> interoperability.... yet we have plenty of these (for obvious
>> reasons) in the corresponding specs).
> 
> I think you are conflating issues here.  Authentication requires
> both ends to use the same mechanism (hence the need for
> interoperability since there are multiple authentication
> mechanisms).

But once you are employing an auth method, there's the question of
what to do if you receive an un-authenticated packet/chunk_of_data.
The policy of dropping or accepting such a packet/chunk is one of
security rather than of interoperability. But, for obvious reasons,
you'd specify to drop such packets/chunks. If we just specify for
interoperability, then this question would remain unaddressed.

>> That said, and as noted above, I have no issues with proceeding
>> as you suggested if that's deemed as the right way to go.
> 

Yep.

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Dec 2014 08:19:28 +1300

Hi,

> issue in protocol specs are those that affect interoperability?

There are precedents the other way, for example RFC 4941 specifies
algorithms for pseudo-random IIDs at SHOULD level, and RFC 7217 has a
MUST. But for the flow label (RFC 6437), we chose not to specify an
algorithm; we just specified that the values SHOULD be chosen from a
uniform distribution.

   Brian C

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Dec 2014 18:20:49 -0300

> algorithm; we just specified that the values SHOULD be chosen from a

That was exactly my point. Actually, IMHO it would be too bad to only
focus on the interoperability implications and just ignore the security
aspects.

Thanks,