Hi, Brian, On 06/01/2011 07:09 PM, Brian E Carpenter wrote: > My to-do list included running your algorithm against the > same datasets. However, I just looked at your draft again and > it seems to be underspecified - you do not define what functions > F and G are.
To some extent, this was intentional. -- Although I do agree I should have noted (non-normatively) that MD5 would be a good choice for F(). As for G(), one could use MD5(), or even something simpler. > And I think it's stateful, because of the statement > "if(three-tuple is unique)". Not sure what you mean. The specs themselves argue that a flowid shouldn't be reused if it's already in use. So one could envision that the flowid used for a communication instance is stored in the corresponding TCB, and that's how it is checked. Anyway, the same algorithm could be used without performing that check, and simply having faith in the algorithm on the fact that collisions will not occur. :-) > All we are discussing is a non-normative suggested algorithm, > so this is not critical for the draft to go forward IMHO. It looks like such an algorithm would belong to a separate document -- particularly if the suggestion is going to be "non-normative". i.e., a separate document could evaluate different algorithms, in a similar way we have done so for transport protocol port number randomization. -- BTW, still wondering what could be a sensible way forward for draft-gont-6man-flowlabel-security. Thanks! Best regards, -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
