Subject: [bmwg] Fwd: Re: Comments on draft-ietf-bmwg-hash-stuffing-05.txt

From: Al Morton <[email-masked]>
Date: Mon, 17 Apr 2006 12:44:20 -0400

BMWG,

Forwarding additional comments from the Security Directorate
review, these are from Jeffrey Altman.

Al
bmwg co-chair

>X-VirusChecked: Checked
>X-Env-Sender: [email-masked]
>X-Msg-Ref: server-2.tower-124.messagelabs.com!1144907385!8914993!1
>X-StarScan-Version: 5.5.9.1; banners=-,-,-
>X-Originating-IP: [128.59.29.8]
>X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
>Date: Thu, 13 Apr 2006 01:52:01 -0400
>From: Jeffrey Altman <[email-masked]>
>Organization: No Longer Affiliated with Columbia University in the City of
>  New York
>User-Agent: Thunderbird 1.5 (Windows/20051201)
>To: "Salowey, Joe" <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked]
>Subject: Re: Comments on draft-ietf-bmwg-hash-stuffing-05.txt
>X-Enigmail-Version: 0.94.0.0
>X-No-Spam-Score: Local
>X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
>
>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
>

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg