Subject: [bmwg] Security section standard text for BMWG documents

From: "Chip Popoviciu \(cpopovic\)" <[email-masked]>
Date: Tue, 3 Oct 2006 16:02:53 -0400

Al,
 
I was wondering if we settled on a default text for the Security section
of the BMWG drafts. The last version I have is:
 
>  Benchmarking activities as described in this memo are limited to
>  technology characterization using simulated stimuli in a laboratory
>  environment, using a dedicated address space and the constraints
>  specified in the sections above.
>  
>  The benchmarking network
>  topology will be an independent test setup and MUST NOT be connected
to
>  devices that may forward the test traffic into a production network,
>  or miss-route traffic to the test management network.
>  
>  Further, benchmarking is performed on a "black-box" basis,
>  relying solely on measurements observable external to the DUT/SUT.
>  
>  No special benchmarking capabilities should exist in the DUT/SUT,
>  therefore disabling such capabilities when the device is used in
>  a production network will not be necessary, and there are no
>  corresponding implications for network security.
 
We are finalizing the new version of the IPv6 benchmarking draft and
wanted to include the right text for the Security section.
 
Best Regards,
Chip
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Al Morton <[email-masked]>
Date: Tue, 03 Oct 2006 18:24:27 -0400

At 04:02 PM 10/3/2006, Chip Popoviciu \(cpopovic\) wrote:

We are
finalizing the new version of the IPv6 benchmarking draft and wanted to
include the right text for the Security section.

Best Regards,

Chip

Chip,

Folks moved on to other things and the discussion

came to a resting place, so I don't think we reached

a final consensus on the wording.  But I can say that:

David Newman responded to my attempt at a summary

(I think that's the text you reproduced.)

Unfortunately, David's response doesn't appear in the

archives!  But it is on my hard drive, so I've attached

his message with edits below.

I agreed with David's suggestions, and then we discussed

making the paragraph a standard one for the Introduction,

as opposed to introducing all this background info in the

back (where the Security Section resides). David, Aamer Akhter,

and I all agreed with this.

Dan Romascanu raised the possibility that David's SHOULD NOT

might be better as a MUST NOT, in his proposed paragraph:

Special capabilities SHOULD NOT
exist in the DUT/SUT specifically for

benchmarking purposes. Any implications for network security arising

from the DUT/SUT SHOULD be identical in the lab and in production
networks.

Also, Dan made a comment about debugging mode that tended to

agree that we were raising more than security-related points

in the text.

So, if you implement the edits in David's message below,

and give some thought to the SHOULD NOT/MUST NOT point

AND decide *where* you'd like to see this paragraph in your memo,

then you'll be contribution to the discussion by providing

the IPv6 author team's view of the "standard"
paragraph.

thanks and regards,

Al

====== David's message follows
=====================================

Date: Sat, 22 Jul 2006 13:04:06 -0700

From: David Newman <[email-masked]>

Organization: Network Test Inc.

User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)

To: [email-masked]

Subject: Re: [bmwg] "Standard" Security Section Paragraph

X-Enigmail-Version: 0.94.0.0

X-Spam-Score: 0.0 (/)

X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135

X-BeenThere: [email-masked]

X-Mailman-Version: 2.1.5

List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>

List-Unsubscribe:
<
https://www1.ietf.org/mailman/listinfo/bmwg>,

<
mailto:[email-masked]?subject=unsubscribe>

List-Post:
<
mailto:[email-masked]>

List-Help:
<
mailto:[email-masked]?subject=help>

List-Subscribe:
<
https://www1.ietf.org/mailman/listinfo/bmwg>,

<
mailto:[email-masked]?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

> specified in the sections above.

s/simulated/controlled/

(stimuli are real, they just occur in a lab)

s/using a dedicated/with dedicated/

("with" avoids repetition of "using")

(deletion of article "a" covers use of multiple noncontiguous
address

spaces)

to

> or miss-route traffic to the test management network.

s/miss-route/misroute/

> corresponding implications for network security.

Sorry, still two issues here:

1. Logic problem in the first two clauses. If special capabilities
do

not exist, then by definition they cannot be disabled in production
or

anywhere else.

Perhaps instead:

"Special capabilities SHOULD NOT exist in the DUT/SUT specifically
for

benchmarking purposes. Any implications for network security arising

from the DUT/SUT SHOULD be identical in the lab and in production
networks."

2. In fact, we frequently use "special capabilities" in
testing. We

enable debug mode, we use special checked builds, we put interfaces
into

promiscuous mode, and so on.

There's an important point being made here, but fundamentally it's not
a

security issue. While I agree 100 percent with this point, I'm not
sure

it belongs as a security consideration. The only security-specific
bit

is the part saying that lab and production security implications
should

not differ.

dn

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEwoS2yPxGVjntI4IRAg4RAJwKKJwtvlfLVVhQK3K4gDQPCk5c/gCg6Ejh

qb0ZhFBzh8VoLopDBh315BM=

=Si1z