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

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Sun, 23 Jul 2006 11:46:36 -0400

Hi Al,

I like the new one with the exception of this line:

>  Further, benchmarking is performed on a "black-box" basis,
>  relying solely on measurements observable external to the DUT/SUT.

It is unclear what this has to do with security. The line following the above seems fine and clear standing on its own.

Regards,

-- 
Aamer Akhter / [email-masked]
NSITE, cisco Systems

>  -----Original Message-----
>  From: Al Morton [mailto:[email-masked]]
>  Sent: Saturday, July 22, 2006 1:43 PM
>  To: [email-masked]
>  Subject: RE: [bmwg] "Standard" Security Section Paragraph
>  
>  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 11:51 AM 7/21/2006, Rajiv Papneja wrote:
>  >[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.
>  
>  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,
>  >
>  >"... relying solely on measurements observable external to the DUT/SUT."
>  
>  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.
>  
>  <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: Al Morton <[email-masked]>
Date: Wed, 26 Jul 2006 16:42:48 -0400

Hi Aamer,

At 11:46 AM 7/23/2006, Aamer Akhter \(aakhter\) wrote:
>It is unclear what this has to do with security. The line following the 
>above seems fine and clear standing on its own.

I think it's a bit of background for the reader, to set-up the
thoughts that follow.

What if the whole paragraph were in the Introduction, instead?

Al
(participant)