Subject: [Nea] REQ: section 6 comments

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 26 Feb 2007 02:25:46 -0000

Section 6 comments/questions:
1.	 Section 6.1.1 - Consider decomposing the example scenario into more
discrete use cases.  In the current scenario you have initial connect-time
assessment intermingled with the re-assessment use cases.  Mixing together
use cases makes defining clear requirement more difficult. 

2.	 Section 6.1.1.2 - I don't believe step 14 is true.  After the OS
Patch validator signals success it's highly unlikely the user will
physically re-connect to the network to get a re-assessment started.  I
suspect the NEA components have some facility to request global
re-assessment, right?

3.	Section 6.1.1.3 - Not sure what this section is trying to say.  This
section does highlight some characteristics of the example scenario, but I
don't see how this translates into impact on requirements.  Consider adding
additional discussion to clarify. 

4.	Section 6.1.2 - What is meant by network service?  Isn't the
scenario described by section 6.1.1 essentially also an example of a request
for a network service?  Please compare/contrast somewhere initial network
connect and request for network service.

5.	Section 6.1.2.1 - This example triggered in my mind a new derivative
use case.  Namely, what about a use case that involves the need to pass
multiple [concurrent] assessments?  For example, what if I'm a guest at a
company that provides guest LAN network connectivity as long as I pass
muster via NEA.  What if then I desire to connect back via VPN to my
company's network that also requires passing security muster via NEA.  This
seems like a realistic and probable use case.  Would NEA protocols support
this?

6.	 Sections 6.1.2.3, 6.1.3.3, 6.2.1.3, 6.2.2.3 - same comment as for
section 6.1.1.3.

NITS

A.	Superfluous commas around "collectively" in first sentence of
section 6.0

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 26 Feb 2007 19:53:07 -0800

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:26 PM
> To: [email-masked]
> Subject: [Nea] REQ: section 6 comments
> 
> discrete use cases.  In the current scenario you have initial 
> connect-time assessment intermingled with the re-assessment 
> use cases.  Mixing together use cases makes defining clear 
> requirement more difficult. 

One of the goals of the spec was to broadly describe the problem space
in the use case (examples.)  We carefully allocated different aspects of
the problem space to each of the 5 use case areas.  We recognized that
the 1st use case was pretty complex (but is likely a well understood
scenario) so you'll note step 14 doesn't go into the re-assessment
details.  If we separated out the remediation it wouldn't make this much
simpler (removes steps 14-16 only.)

> Patch validator signals success it's highly unlikely the user 
> will physically re-connect to the network to get a 
> re-assessment started.  I suspect the NEA components have 
> some facility to request global re-assessment, right?

Correct, we'll try to fix the wording.  Note however that step 1 doesn't
mention booting or user interaction just that: "The IT employee's
desktop computer connects to the network...".  If it helps we could
address this comment.

> section does highlight some characteristics of the example 
> scenario, but I don't see how this translates into impact on 
> requirements.  Consider adding additional discussion to clarify.

Ok.  These are "different aspects of the problem space" mentioned above
that could impact the requirement definitions.  Some text to explain
this would be helpful.

> scenario described by section 6.1.1 essentially also an 
> example of a request for a network service?  Please 
> compare/contrast somewhere initial network connect and 
> request for network service.

I presume the example given in 6.1.2 wasn't sufficent (detailed enough)?
One could imagine this being a request to a protected service like the
Financial Portal server which contains very sensitive and mission
critical data.  We used the example of VPN to show an L3 (instead of L7)
service request but as you mention this smells similar to the L2 initial
network connect example.  We could switch it if others feel this is
important.

> use case.  Namely, what about a use case that involves the 
> need to pass multiple [concurrent] assessments?  For example, 
> what if I'm a guest at a company that provides guest LAN 
> network connectivity as long as I pass muster via NEA.  What 
> if then I desire to connect back via VPN to my company's 
> network that also requires passing security muster via NEA.  
> This seems like a realistic and probable use case.  Would NEA 
> protocols support this?

Certainly more complicated and I'm not sure this introduces an aspect of
the problem space that we didn't already cover.  I presume this would
just be 2 independent assessments without knowledge of each other (?).

> 6.	 Sections 6.1.2.3, 6.1.3.3, 6.2.1.3, 6.2.2.3 - same 

Yes

> A.	Superfluous commas around "collectively" in first sentence of

Thanks