I have reviewed this document. My comments are interspersed with Joe's.
Salowey, Joe wrote:
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.
The draft currently contains the sentence:
"This attack could consume up to 100 percent of available bandwidth.
However, the test networks described in BMWG documents generally
SHOULD NOT be reachable by anyone other than the tester(s)."
which seems to imply that except in extra ordinary cases the networks
used for BMWG testing SHOULD be private. I had the same reaction as Joe
that it should be explicitly indicated that public networks SHOULD NOT
be used unless all the affected parties have either given approval or
been notified.
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 than
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.
Section 3.1 of the draft indicates that "Repeatability" is a desired
goal of the benchmarking. As such use of rand() with a fixed seed would
appear to be an appropriate source of input data provided that the
output sequence did in fact provide for a uniform distribution of values.
Section 3.2 of the draft describes the "Randomness" requirements of
benchmarking.
"This document recommends the use of pseudorandom patterns in test
traffic under controlled lab conditions. The rand() functions
available in many programming languages produce output that is
pseudorandom rather than truly random. Pseudorandom patterns are
sufficient for the recommendations given in this document, provided
they produce output that is uniformly distributed across the pattern
space.
"Specifically, for any random bit pattern of length L, the
probability of generating that specific pattern SHOULD equal 1 over 2
to the Lth power."
I do not believe the use of randomness in this draft is a security
consideration. The question I am left with is, is repeatability more
or less important than randomness? If randomness is more important
than I believe a variation on Joe's text is appropriate. If
repeatability is more important, then I believe a stronger
recommendation of rand() and specified seed values would be appropriate.
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?
This comment makes me wonder whether there should be an index of
security considerations such that all of the types of security
considerations are listed along with the documents in which they appear.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf