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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf