I reviewed this document ( Hash and Stuffing: Overlooked Factors in Network Device Benchmarking ) as part of a cross area security review. In general I think the document looks OK. I have a few comments: 1. It might be nice if the document stated something along the following in the security considerations section: "Injecting random traffic into a network can result in disruption of service and the raising of security and fault alarms. These tests must not be performed on a network without prior approval from the network owners and operators. These tests should not be performed on a production network." This may seem like common sense, but stuff happens. 2. Use of pseudorandom number generators The behavior of pseudo random generators is implementation specific, they are not all created equal. PRNGs may have biases that make them unsuitable for security applications or numerical simulations. I have not done a detailed analysis of the application to testing, but in general I think testing applications are less sensitive. If enough test data is consumed then non-ideal behavior make cause artificial patterns in the test result data. Some low quality PRNG's may also exhibit biases. RFC 4806 describes ways to deal with some of these problems for security applications. The recommendations here would be sufficient for testing applications, although they would probably overkill. One thing to be aware of with PRNG implementations is that they depend upon a seed. For the same seed (initial state) they give the same output. Different implementations may treat seeds and internal state management differently. Making subsequent calls to the same PRF with the same seed will often result in the same sequence. This could result in a less than uniform distribution depending on how the seeding is done. Maybe the document should state something along the following lines: "This document recommends the use of pseudorandom patterns in test traffic. This usage requires a uniform distribution, but does not have strict predictability requirements. The recommendations in RFC 4806 are for security applications and would produce output that is more that sufficient for testing applications. Although it is not sufficient for security applications, the rand() function of many programming languages may provide a uniform distribution that is usable for testing purposes. Implementations of rand() may vary and provide different properties so test designers should understand the distribution created by the underlying function and how seeding the initial state affects its behavior. " I don't think this text belongs in the security section, if it does then it should recommend following RFC 4806. 3. (More of a note to the IETF and IESG) This document highlights some areas which are general security issues. For example the document does mention stuffing vulnerabilities. These are discussed in some protocol documents, but there undoubtedly some instances where they are not discussed. Perhaps this warrants general discussion and possibly a document on stuffing vulnerabilities. Perhaps the same is also true of the address skew vulnerabilities, I need to think about it some more. I remember an IAB document on DOS vulnerabilities from a while ago, what is the status of this document and did it discuss any of these issues? Let me know if you have any questions or comments. Cheers, Joe _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf