Subject: [secdir] review of draft-ietf-6man-predictable-fragment-id-09

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Wed, 9 Sep 2015 10:12:43 +0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes security implications of predictable values for the identification field in fragment headers for IPv6.

I believe the document has some issues, see below.

The document does an analysis of the security implications of predictable identification fields and I believe (not being an IPv6 expert) that it does a good job at that. The analysis of the potential exploits is convincing.
Where I am struggling a bit is the algorithms for selecting fragment identification values (5).

The intro text states that there are ‘a number of algorithms', but really there are only 3:
1- per destination counter random initialised
2- random value
3- hash over source, destination, secret with a counter

1 and 3 are essentially the same, the hash function in 3 performs the same function as the pseudo random generated initial value in 1 if I am not mistaken.
So really the choice is between a random value for every datagram or a random value at initialisation of a connection and increasing by 1 for every subsequent datagram.

I’d really like to see some quantitative analysis as to the impact of a random value per packet as well as between 1 and 3. Now, as an implementer I will know about the vulnerability but can not really determine what mediation route to follow.

So to sum up, I really liked the analysis part, but I would prefer some work on the solution to the problem part.

Klaas

--
Klaas Wierenga
Identity Architect
Cisco Cloud Services

---

From: Fernando Gont <[email-masked]>
Date: Wed, 9 Sep 2015 07:58:49 -0300

Hi, Klaas,

Thanks so much for your feedback! -- Please find my responses in-line...

On 09/09/2015 07:12 AM, Klaas Wierenga (kwiereng) wrote:
> The document does an analysis of the security implications of
> predictable identification fields and I believe (not being an IPv6
> expert) that it does a good job at that. The analysis of the
> potential exploits is convincing. Where I am struggling a bit is the
> algorithms for selecting fragment identification values (5).
> 
> The intro text states that there are ‘a number of algorithms', but
> really there are only 3: 1- per destination counter random
> initialised 2- random value 3- hash over source, destination, secret
> with a counter

FWIW, these are three concrete algorithms, but that doesn't mean they
are the only possible ones...

> 1 and 3 are essentially the same, the hash function in 3 performs the
> same function as the pseudo random generated initial value in 1 if I
> am not mistaken.

Yes and no. 1 requires state, but 3 doesn't. That means that, e.g., if
you have lot's of flows to many different destinations, you may need to
remove some entries from the Dest Cache (and then you run the risk of
Frag ID collisions). However, this is not the case with algorithm #3.

> So really the choice is between a random value for
> every datagram or a random value at initialisation of a connection
> and increasing by 1 for every subsequent datagram.
> 
> I’d really like to see some quantitative analysis as to the impact of
> a random value per packet as well as between 1 and 3.

Impact in terms of what?

Thanks!

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

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Wed, 9 Sep 2015 12:02:37 +0000

Hola Fernando,

> are the only possible ones…

Sure, I understand that. It is just when I read it I was preparing for a long list to come, so I think it would be good to state something like:

OLD

This section specifies a number of algorithms that may be used for
   selecting Fragment Identification values.

NEW

There are a number of algorithms that may be used for selecting Fragment Identification values. This section presents three of those.

--

> Frag ID collisions). However, this is not the case with algorithm #3.

good point, so is there any compelling reason to select 1 over 3?

>> a random value per packet as well as between 1 and 3.

Well, as an implementer I want to choose between one of the algorithms you propose. But since I have no clue what the penalty is for doing per packet randomisation as opposed to per flow that is hard. If the cost of a pseudorandom operation is outweighed by other factors involved in sending a packet I would probably choose option 2. My gut feeling says however that it is a pretty expensive operation to do on a per packet basis, so I would expect the advise  to be “use 1 or 3” unless…..  And similarly, what is the cost of the hash versus the prg? If they are comparable would option 3 not be better?

Does that make sense?

Klaas