Hi, I am happy with the updated draft. Klaas -- Klaas Wierenga Identity Architect Cisco Cloud Services > On 01 Oct 2015, at 23:51, Fernando Gont wrote: > > Hi, Klaas, > > On 09/09/2015 07:02 AM, Klaas Wierenga (kwiereng) wrote: >>> On 09/09/2015 07:12 AM, Klaas Wierenga (kwiereng) wrote: >>>> 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 >>> >>> FWIW, these are three concrete algorithms, but that doesn't mean >>> they 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. > > Will do. (thanks for proposing a way forward, btw). > > > >>>> 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. >> >> good point, so is there any compelling reason to select 1 over 3? > > It is generally the other way around: for #1, if you need to remove the > state from the Destinations Cache, you run the risk of colliding Frag > IDs. So you could say that #1 is more trivial to implement, whereas #3 > has better properties (when there are ongoing communications with > multiple destinations that make you hit the limit of entries in the > Destination Cache). > > > >>>> 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? >> >> 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. > > Wel, the thing is that, to a large extent, it depends on the details of > implementation. e.g., what's the algorithm you use for the randon() > function, etc. > > > >> 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….. > > We tried to provide options rather than pushing one specific algorithm. > > >> And similarly, what is the cost of the >> hash versus the prg? If they are comparable would option 3 not be >> better? > > It depends on which hash function vs PRG. For instance, you could employ > a hash function for the PRG. > > So any assertion on performace would really be questionable... > > Thoughts? > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > >