Subject: [bmwg] Fwd: RE: SecDir Review: draft-ietf-bmwg-hash-stuffing-05.txt

From: Al Morton <[email-masked]>
Date: Wed, 12 Apr 2006 12:09:54 -0400

BMWG,

Forwarding comments from Joe Salowey, who responded
to our WG's request for cross-area review.

Al
bmwg co-chair

>X-VirusChecked: Checked
>X-Env-Sender: [email-masked]
>X-Msg-Ref: server-6.tower-120.messagelabs.com!1144857516!10533974!1
>X-StarScan-Version: 5.5.9.1; banners=-,-,-
>X-Originating-IP: [171.68.10.86]
>X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
>X-IronPort-AV: i="4.04,115,1144047600";
>    d="scan'208"; a="1794289389:sNHT663386342"
>Subject: RE: SecDir Review: draft-ietf-bmwg-hash-stuffing-05.txt
>Date: Wed, 12 Apr 2006 09:05:50 -0700
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>Thread-Topic: SecDir Review: draft-ietf-bmwg-hash-stuffing-05.txt
>Thread-Index: AcZdpAjxS9siqRIKTI6erIkdgMhN3QApRELw
>From: "Salowey, Joe" <[email-masked]>
>To: "Al Morton" <[email-masked]>
>
>Sure, please do.  Below are revised comments based on Sam's comments.  I
>will send these to the IESG and IETF lists as well.
>
>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
>
> > -----Original Message-----
> > From: Al Morton [mailto:[email-masked]]
> > Sent: Tuesday, April 11, 2006 1:04 PM
> > To: Salowey, Joe
> > Subject: RE: SecDir Review: draft-ietf-bmwg-hash-stuffing-05.txt
> >
> > Thanks Joe, this will be very helpful for the authors.
> >
> > Would you mind if I share your comments with the entire
> > BMWG list?
> >
> > Al
> >
> > At 03:13 PM 4/11/2006, Salowey, Joe wrote:
> > >In general I think the document looks OK.  I have a few comments:
> >

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

---

From: David Newman <[email-masked]>
Date: Wed, 12 Apr 2006 09:53:38 -0700

> to our WG's request for cross-area review.

Thanks very much for Joe's thoughtful comments.

We're very willing to beef up the language about randomness in the security
considerations section. Even though this ID isn't about network security,
the issues regarding randomness definitely apply.

We're less open to the first suggestion about the warning label, unless the
bmwg is willing to consider reissuing all RFCs for which it would apply.
Experience from a few accidents suggests that leaks from 2544 or 2889 tests
can create all sorts of excitement on production networks, regardless of
whether traffic is randomly addressed.

This seems like one of those McDonald's coffee-is-hot lawyer labels,
especially given that the bmwg charter explicitly declares live network
testing to be out of scope.
 
dn/tcp

---

From: Al Morton <[email-masked]>
Date: Wed, 12 Apr 2006 13:36:09 -0400

>testing to be out of scope.

You're right, the concern isn't specific to use of random addresses.

The perspective I'd like to add here is that hash-stuffing provides
additional considerations for 2544 and 2889, so that they do not have
to be re-issued. There appears to be an opportunity to remind
testers about our charter/scope in the security section here,
and 2544 or 2889 don't do it adequately in their security sections
(I have not checked to see if either says "no live net testing"
somewhere else).

Al