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

From: "Rajiv Papneja" <[email-masked]>
Date: Fri, 21 Jul 2006 11:51:22 -0400

Hello Al,

This is really good effort to ease the bottlenecks down the road. I am fine
with the text except a question, or clarification.

/R

Please see my comments below:
> If we reach consensus on some text, I'll post it on our
> supplementary web page.  Thanks for your attention to this topic.
> 
> Al
> bmwg co-chair
> 
> 
> Security Considerations
> 
> Benchmarking activities as described in this memo are limited to
> technology
> characterization using simulated stimuli in a laboratory environment,
> and a dedicated address space. The benchmarking network topology MUST NOT
> be connected to devices that may forward the test traffic into a
> production
> network environment. 
[rp] the topology is typically connected to the management network, however,
if it is connected we should ensure proper filters (for ex. No default
routes configured) are in place to ensure no traffic is mis-directed to the
management LAN.
> Further, benchmarking is performed on a "black-box"
> basis, and no abnormal configuration settings should be necessary.
> No special benchmarking capabilities should exist in a device under test,
> so there should be no need to disable such capabilities when the device
> is used in a production network.
> 
> 
> <Add any additional security considerations, specific to this memo.>
> 
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 

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

---

From: David Newman <[email-masked]>
Date: Fri, 21 Jul 2006 09:16:36 -0700

Al Morton wrote:

> The benchmarking network topology MUST NOT
> production network environment.

Concur with earlier comment about test network management. This is
literally OK as is, since it's not the "benchmarking network topology"
that's connected elsewhere. But I'd recommend deleting this sentence,
since the first sentence already makes clear that testing is done in a
lab with dedicated address space.

If we were to include a follow-up sentence to the first one, I'd suggest
something like "we're measuring network elements and not live networks
here; go see ippm for the latter." But I really don't think that's
needed either since the first sentence already declares the scope.

> basis, 

delete:

and no abnormal configuration settings should be necessary.

and substitute:

"... relying solely on measurements observable external to the DUT/SUT."

> is used in a production network.

What are the security implications here?

I'm all for avoidance of "tuning for benchmarks," where vendors supply
cooked code for optimal performance in a lab test. That's not a security
issue, however.

Did you instead mean that no DUT/SUT security capabilities should exist
specifically for lab testing, so there should be no need to disable or
alter such capabilities in production settings?

dn

---

From: Al Morton <[email-masked]>
Date: Sat, 22 Jul 2006 13:43:26 -0400

Thanks for all the responses thus far.
Let me try to summarize the discussion and suggestions for
re-wording:

Based on the constructive nature of the comments and positive reactions,
this paragraph appears to be worthwhile to pursue further.

First Sentence: "Scope of BMWG covers this memo"
No disagreement with this, it was mostly borrowed from the
charter, so it's not controversial. Arun added a phrase
to the end to reference earlier constraints.

Second Sentence: "Requirement restricting connectivity"
Most agreed with stating an explicit requirement here,
using the RFC 2119 terminology. The requirement itself
is what this sentence adds.  The management LAN was explicitly
mentioned and concurred, although there was a question about the
degree of detail we should include here.

At 03:40 PM 7/21/2006, Arun Gandhi wrote:
>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.

Third and Fourth Sentences: "No DUT capabilities unique to benchmarking"
Here, I tried to dispel the notion that our tests require
something special in every DUT, something that needs to be turned off
before the DUT leaves the lab. This came-up once already, so it
seemed worthwhile to state one of our fundamental principles.

At 12:16 PM 7/21/2006, David Newman wrote:
> > Further, benchmarking is performed on a "black-box" basis,
>

At 11:35 AM 7/21/2006, Romascanu, Dan \(Dan\) wrote:
>None of the benchmarking capabilities defined in this document
>should be implemented in a device
>under test, thus the behavior of network devices in Internet
>deployments is not modified and does not have any security
>implications in production networks.

At 03:40 PM 7/21/2006, Arun Gandhi wrote:
>Further, benchmarking is performed on a "black-box" basis and there
>should not be a need for any special configuration settings. Therefore,
>disabling such capabilities when the device is used in a production
>network will not be necessary.

So, I've attempted to craft four sentences that capture
the thoughtful comments received thus far.

More tweaking is welcome, especially if anyone felt I missed
their point.

Al
(as a participant, just editing the security paragraph)

Summary: Security Considerations

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.

---

From: Al Morton <[email-masked]>
Date: Sat, 22 Jul 2006 22:14:54 -0400

At 04:04 PM 7/22/2006, David Newman wrote:
>s/simulated/controlled/
>
>(stimuli are real, they just occur in a lab)

Need to fix this in the next charter update,
same wording there.

>...
>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."

Much better, IMO.

>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.

Agree, although most of the capabilities listed
above are for general testing/troubleshooting,
and not unique to benchmarking.
Anyone benchmarking with debug on?
(except in Accelerated Stress, of course, and a opportunistic
reminder to read these drafts during their WG last call)

>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.

Yes.  Sometime after I pressed "Send" on Friday morning,
I began to think that this paragraph might work better as a standard
part of our Introduction Sections.  It would help to set the scope
if it appeared right up front, and every reader
would carry this important background into the memo.
Kind of like the first page in every owner's manual:
*Warning - Read This Before Operating Your New <tool with sharp teeth>*

I wanted to see if anyone else would reach a similar conclusion.
We are attempting to deal with Directorate reviews other than Security,
too.

Al

---

From: David Newman <[email-masked]>
Date: Sat, 22 Jul 2006 20:22:59 -0700

> Anyone benchmarking with debug on?

Frequently for troubleshooting, and once in a while to determine the
performance cost of logging (eg, different syslog levels).

> We are attempting to deal with Directorate reviews other than Security,

Experience suggests this makes more sense in the introduction than
tucked into security considerations at the end. Reviewers of both dsterm
and hash-stuffing have complained that these IDs aren't appropriate for
production networks, when neither was intended to be.

Having the disclaimer right up front would help reduce confusion,
especially for reviewers outside bmwg.

dn