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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 21 Jul 2006 18:35:30 +0300

Al,

I suggest that when the WG reached consensus wrt. this text, we also run
it with the Security Area Directors. 

Now, as a contributor: 

Wrt. the text:

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

So far so good, IMO. 

> Further, benchmarking is performed on a 
> "black-box"
> basis, and no abnormal configuration settings should be necessary.

I am not sure that I understand this phrase, and why it belongs to
Security Considerations. 

Also, I would suggest: 

OLD:

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

NEW:

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

Regards,

Dan

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 23 Jul 2006 09:26:41 +0300

In-line. 

Regards,

Dan
(speaking as contributor)

> -----Original Message-----
> From: David Newman [mailto:[email-masked]] 
> Sent: Saturday, July 22, 2006 11:04 PM
> To: [email-masked]
> Subject: Re: [bmwg] "Standard" Security Section Paragraph
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> minor copy-editing nits and two comments:
> 
> > 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.
> 
> 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)
> 
> > 
> > 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.
> 
> s/miss-route/misroute/
> 
> > 
> > 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.
> 
> 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."

Why use SHOULD and not MUST? 

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

I am not sure that the existence of a debugging mode that can impact
performance of the DUT/SUT and/or provide information internal to the
device should not be considered as DOS and disclosure security threats. 

Dan

> 
> dn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> 
> iD8DBQFEwoS2yPxGVjntI4IRAg4RAJwKKJwtvlfLVVhQK3K4gDQPCk5c/gCg6Ejh
> qb0ZhFBzh8VoLopDBh315BM=
> =Si1z
> -----END PGP SIGNATURE-----
>

---

From: "Heininger, Gabriel" <[email-masked]>
Date: Wed, 26 Jul 2006 13:25:10 -0700

>From an automation perspective, *if* you are doing white box testing you could end up with user names, passwords, RADIUS accounts, SNMP community names, etc. in test scripts and/or configuration files. If tests were performed on a go-live configuration (i.e. no more configuration changes) this could prove to be a security hazard. This may fall into the realm of test "strategy" rather than methodology, but I thought it should be mentioned.

Gabe

-----Original Message-----
From: Aamer Akhter (aakhter) [mailto:[email-masked]]
Sent: Sunday, July 23, 2006 8:47 AM
To: Al Morton; [email-masked]
Subject: RE: [bmwg] "Standard" Security Section Paragraph

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

>  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:
>  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
>  
>  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.
>  
>  therefore disabling such capabilities when the device is used in
>  a production network will not be necessary, and there are no
>  <Add any additional security considerations, specific to this memo.>
>  
>  

<DIV><FONT size="1">

E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at [email-masked].

Spirent Communications plc,
Spirent House, Crawley Business Quarter, Fleming Way, Crawley, West Sussex, RH10 9QL, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Spirent House, Crawley Business Quarter, Fleming Way, Crawley, West Sussex, RH10 9QL, United Kingdom 

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300 

</FONT></DIV>

---

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Thu, 27 Jul 2006 09:45:06 -0400

Moving it to an intro would be better IMHO. But this was only a minor line I was nitpicking on in an otherwise fine passage.

Regards,

>  Sent: Wednesday, July 26, 2006 4:43 PM
>  To: [email-masked]
>  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)
>  
>