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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf