Subject: [Nea] REQ: Section 5 comments

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

Several comments/questions about section 5 [Reference Model]:

1.	Meta-comment: The model seems to assume that an endpoint consists of
only one processing entity (OS, hardware, etc.).  It's unclear how the model
and the adjunct requirements may need to get modified in light of rising
popularity in system virtualization.  For example, it likely that multiple
posture broker clients and posture transport clients will exist on single
hardware system  that's been virtualized into multiple systems. I'd say
additional thought is necessary in this area or we just punt and explicitly
say that it's out of scope at this time.

2.	Meta-comment:  Section 9 describes several suggestions on how to
introduce user facilities to manage privacy.  In that section there's no
specific guidance on which components should implement the suggested privacy
enhancements.  If not in section 9, wouldn't it be useful to assign the
privacy enhancements to the model/components described in section 5?  For
example, I could envision seeing the posture collectors and posture broker
client sharing responsibilities in proving a user the necessary UI and
privacy policy management capabilities described in section 9.  

3.	Meta-comment:  The model describes the existence of protocols
between like layers (e.g. posture collector <--PA--> posture validator,
posture broker client <--PB--> posture broker server), but provides no
description as to what happens between different layers (posture collector
<-> posture broker).  I suspect that there's an unwritten assumption that
different layers may communicate using APIs.  If so, I suggest that at a
minimum there be some suggestion on how different layers may be
communicating (e.g. APIs) and noting that such work is out of scope for the
current WG charter (and IETF in general). 

Side note:  Section 5.1.2.2 states that validators may be physically remote
to the server.  Doesn't this particular situation give rise to yet another
protocol for the NEA model to denote?   I can imagine the existence of a PV
(Posture Validator) protocol between a remote posture validator and a
posture broker server.  Even though the current WG charter precludes working
on any protocol other than PA and PB, we should nonetheless strive for
completeness in the description of the model. 

4.	Meta-comment:  The document introduction (section 1.0) describes the
existence of an enforcement entity to enforce the final admission decision.
Although I understand that mechanisms and protocols for enforcement are out
of scope, shouldn't the NEA model diagram and description at least
acknowledge that an enforcement entity exists?  There should be a general
goal of having a comprehensive ENA model, even if complete treatment of all
components and protocols are not currently within NEA charter. 

5.	Section 5.0: Discussion of reference model includes statement: "This
model is provided to establish a context for the discussion of requirements
and may not directly map to any particular product or deployment
architecture." This statement seems to contradict the statement made in the
abstract that the NEA reference model is based on the models used by CNAC,
NAP and TNC.  

6.	Section 5.1.1.1, last paragraph:  From an interoperability
perspective NEA should evaluate mandating a minimum amount of functionality
so as to improve the odds of interoperable implementations.   Or at a
minimum there should be some form of signaling introduced into the protocol
to provide for component capability advertisement. 

7.	Section 5.1.1.2, first paragraph, second sentence: "...forwarding
the request to the appropriate Posture Collectors."  This sentence sounds
like a request always goes to multiple collectors.  I don't believe this is
always the case, or is it?  

8.	Section 5.1.1.2, first paragraph, third sentence: "The Posture
Broker Client also multiplexes the responses from the Posture Collector..."
This sentence doesn't acknowledge that there may be one or more posture
collectors.  Consider changing to "...multiplexes the responses from Posture
Collector(s)..."

9.	Section 5.1.1.3 mentions that there may be more than one posture
transport client on an endpoint.  I suggest updating the diagram of the
model detailing this fact (e.g. add "(1...n)" to posture transport client
block as was done for posture collector).  Furthermore, it'd be useful to
describe why multiple transport clients may be necessary.  

10.	Section 5.1.2.1 mentions that a posture validator may be located on
a separate server from the posture server.  It goes on to say that the
server may have to with both local and remote validators.  One can assume
that in the instance 

11.	Section 5.1.2.2 describes as one of the roles being, "Communicating
with remote Posture Validators and providing cryptographic protection for
this communication."   It's unclear to me what this exactly means.  The
broker server doesn't have any direct relationships with a posture
validator, or does it?  Furthermore, it's not clear at what level the
cryptographic protection is being provided.  In section 5.1.1.3 (about
posture transport client) it state clearly that its role is to protect the
message dialog.  I suggest the same level of clarity for server broker's
role.

12.	Section 5.1.2.2 - Is it not the role of the posture broker server to
also establish the overall compliance decision for an endpoint?  Currently
the document only assigns the generation of the global posture decision.  If
not the broker server, which component generates the overall compliance
decision?  Or is the global posture decision in fact the compliance
decision?  I'm confused.

13.	Section 5.1.2.3 - Why may there be more than one posture transport
server in a particular NEA server?  If there are truly multiple posture
transport servers, then the NEA model diagram should be updated to reflect
this possibility. See comment #8.

14.	Section 5.1.2.3 - The statement "Providing cryptographic protection
for Posture information." is not as clear as the one used for the posture
transport client. For the posture transport client the described role is
protection of message dialog.  It's probably the same for the transport
server and should be designated as such in the document. 

15.	Section 5.3.1 - I sense there is at some level some relationship
between the attributes sent by a NEA server (i.e. requests) and those sent
by a NEA client (i.e. responses).  For example, isn't it the case that
request attributes always and only elicit posture attributes as a response?
Likewise, couldn't the same be said of policy attributes and compliance
claim attributes?  If so, it may be useful to highlight these relationships
to make the protocol easier to understand. 

16.	Section 5.3.2 - It's unclear to me to what level the remediation
attributes will get defined.  On one hand the intro to this section (5.3)
states that NEA WG will define a standard set of attributes.  By the same
token other parts of the document (e.g. section 3.1 - scope) state the
standard protocols for remediation are out of scope.   In defining
remediation attributes are we not inadvertently defining a standard protocol
for remediation? 

NITS 
a. Misplaced period in last sentence of section 5. [Reference model]. Period
goes outside parenthesis bracket. 
b. Misplaced commas and periods in first sentence of 5.1.1.1 
c. Misplaced period in last sentence of second paragraph of section 5.1.1.1.
Same disposition as NIT 3a.
d. Missing period on second bullet of section 5.1.1.2
e. Why is Message Dialog capitalized? See comment 7a.
f. Change "Posture Transport Clients" to "Posture Transport Client" in
section 5.1.1.3, first paragraph, last sentence.

--------------------------------------------
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 23:26:58 -0800

Many thanks for the thorough review!  The Design Team will be working to
incorporate as many of your comments as we can into -01 this week
(assuming other WG members don't object soon.)

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:25 PM
> To: [email-masked]
> Subject: [Nea] REQ: Section 5 comments
> 
> only one processing entity (OS, hardware, etc.).  It's 
> unclear how the model and the adjunct requirements may need 
> to get modified in light of rising popularity in system 
> virtualization.  For example, it likely that multiple posture 
> broker clients and posture transport clients will exist on 
> single hardware system  that's been virtualized into multiple 
> systems. I'd say additional thought is necessary in this area 
> or we just punt and explicitly say that it's out of scope at 
> this time.

Which virtualization model are you concerned about?  Is it hypervisor
style (multi guest OSes and/or virtual appliances) as per a Xen model?
If so, why couldn't the NEA Client just run in each guest OS and provide
Posture like it would in a non-virtualized environment?  If multiple
guest OSes exist, each normally have their own network interfaces
(possibly [para]virtualized) but they could report their Posture when
requested on their interface (or when attempting to connect to the
network.)  The primary difference I see is the potential lack of Posture
about the hypervisor layer but this could be addressed in different
ways.

This might be an interesting dialog to have on the alias to determine if
we need to push this out of scope or whether this is similar enough to
our model that it could remain in scope and be discussed.

> introduce user facilities to manage privacy.  In that section 
> there's no specific guidance on which components should 
> implement the suggested privacy enhancements.  If not in 
> section 9, wouldn't it be useful to assign the privacy 
> enhancements to the model/components described in section 5?  
> For example, I could envision seeing the posture collectors 
> and posture broker client sharing responsibilities in proving 
> a user the necessary UI and privacy policy management 
> capabilities described in section 9.  

This might be a good addition to section 9 to make it more specific.

> between like layers (e.g. posture collector <--PA--> posture 
> validator, posture broker client <--PB--> posture broker 
> server), but provides no description as to what happens 
> between different layers (posture collector <-> posture 
> broker).  I suspect that there's an unwritten assumption that 
> different layers may communicate using APIs.  If so, I 
> suggest that at a minimum there be some suggestion on how 
> different layers may be communicating (e.g. APIs) and noting 
> that such work is out of scope for the current WG charter 
> (and IETF in general). 

These were discussed during the formation of NEA and are out of scope.
We could add a sentence to state this in section 5 (or 3.1.) I'd rather
not make a statement whether they are API or protocol interfaces.

> 
> Side note:  Section 5.1.2.2 states that validators may be 
> physically remote to the server.  Doesn't this particular 
> situation give rise to yet another
> (Posture Validator) protocol between a remote posture 
> validator and a posture broker server.  Even though the 
> current WG charter precludes working on any protocol other 
> than PA and PB, we should nonetheless strive for completeness 
> in the description of the model. 

This was discussed as well during the BOFs but was also removed from the
final reference model presented by the chairs during the San Diego NEA
WG meeting and the model used prior to our approval to become a WG.
The current model only names the protocols we intend to specify
requirements for in this spec.  With that said we did want to mention
that the Posture Validators could be remote in the text (as you noted)
because this might impact the security model and it helps understand why
a deployer might wish to use strong security protections on the PA
Messages.  Did you have a specific change in mind?  Is it something we
can mention without defining and showing PV as a formal protocol (e.g.
extend some of the text in 5.1.2.[1,2]?)

> Although I understand that mechanisms and protocols for 
> enforcement are out of scope, shouldn't the NEA model diagram 
> and description at least acknowledge that an enforcement 
> entity exists?  There should be a general goal of having a 
> comprehensive ENA model, even if complete treatment of all 

We had this discussion at the NEA WG meeting in San Diego when the
enforcement device was removed from the diagram (pre I-D).  Their has
been a desire by folks in the WG to stay independent of the network
access layer.

> model is provided to establish a context for the discussion 
> of requirements and may not directly map to any particular 
> product or deployment architecture." This statement seems to 
> contradict the statement made in the abstract that the NEA 
> reference model is based on the models used by CNAC, NAP and TNC.

It merely represents the intended use of the model (component and
protocol naming) for the purposes of this document.  The CNAC, NAP and
TNC have similar analogous models which was the point of the abstract.

> minimum there should be some form of signaling introduced 
> into the protocol to provide for component capability advertisement.

Is your point that the Posture Collector could support a fairly wide
variety of classes of Attributes and likely a variety of specific
Attributes so its difficult for a Posture Validator to know which ones
are supported?  When we define the PA protocol, we should be able to
address this issue.  Is their a requirement you'd like to see added for
PA to enable this capability discovery or just add text to 5.1.1.1 to
describe the situation?
 
> the request to the appropriate Posture Collectors."  This 
> sentence sounds like a request always goes to multiple 
> collectors.  I don't believe this is always the case, or is it? 

No its based upon which Posture Collectors are involved (requested to
be) in the assessment.  Will clean-up the text to help.
 
> This sentence doesn't acknowledge that there may be one or 
> more posture collectors.  Consider changing to 
> "...multiplexes the responses from Posture Collector(s)..."

Ok

> transport client on an endpoint.  I suggest updating the 
> diagram of the model detailing this fact (e.g. add "(1...n)" 
> to posture transport client block as was done for posture 
> collector).  Furthermore, it'd be useful to describe why 
> multiple transport clients may be necessary.  

Ok

> a separate server from the posture server.  It goes on to say 
> that the server may have to with both local and remote 
> validators.  One can assume that in the instance 

I can't parse this ...

> broker server doesn't have any direct relationships with a 
> posture validator, or does it?  Furthermore, it's not clear

The Posture Broker Server communicates (API or protocol) with the
Posture Validator(s) to pass PA Messages (and decisions.)
 
> at what level the cryptographic protection is being provided. 
>  In section 5.1.1.3 (about posture transport client) it state 
> clearly that its role is to protect the message dialog.  I 
> suggest the same level of clarity for server broker's role.

Maybe this should be removed since this protocol is out of scope if its
confusing.  We expected that their might be a security protocol between
the Posture Broker Server and Posture Validator.  Within NEA scope, the
PA Messages could be encrypted/integrity protected end-to-end and flow
over this link but the Posture Broker Server doesn't have to do anything
special for this to occur.

> also establish the overall compliance decision for an 
> endpoint?  Currently the document only assigns the generation 
> of the global posture decision.  If not the broker server, 
> which component generates the overall compliance decision?  
> Or is the global posture decision in fact the compliance 
> decision?  I'm confused.

Global posture decision == overall compliance decision

We don't use the expression "overall compliance decision"

> server in a particular NEA server?  If there are truly 
> multiple posture transport servers, then the NEA model 
> diagram should be updated to reflect this possibility. See comment #8.

One for each transport/carrier protocol.  You might imagine one for
IPsec, one for 802.1x, one for SSL, ...  We will consider revising the
diagram.

> for Posture information." is not as clear as the one used for 
> the posture transport client. For the posture transport 
> client the described role is protection of message dialog.  
> It's probably the same for the transport server and should be 
> designated as such in the document. 

Agreed

> between the attributes sent by a NEA server (i.e. requests) 
> and those sent by a NEA client (i.e. responses).  For 
> example, isn't it the case that request attributes always and 
> only elicit posture attributes as a response?
> Likewise, couldn't the same be said of policy attributes and 
> compliance claim attributes?  If so, it may be useful to 
> highlight these relationships to make the protocol easier to 
> understand. 

We'll work to make the relationships more clear.  We did this already
for Compliance Claim and Policy Attributes but not Request and Posture
Attributes.

> attributes will get defined.  On one hand the intro to this 
> section (5.3) states that NEA WG will define a standard set 
> of attributes.  By the same token other parts of the document 
> (e.g. section 3.1 - scope) state the
> remediation attributes are we not inadvertently defining a 
> standard protocol for remediation? 

We decided to define the class of attributes so they can be a distinct
class (possibly becoming a separate name space) but we don't expect NEA
will define the specific attribute names/values due to our charter
limitation.  It was handy to define the term for these attributes so we
could reference where they fit in the model/examples but that is all we
expected would be done with them.

> 
> 
> NITS
> a. Misplaced period in last sentence of section 5. [Reference 
> model]. Period goes outside parenthesis bracket. 

Thanks

> d. Missing period on second bullet of section 5.1.1.2 e. Why 
> is Message Dialog capitalized? See comment 7a.

Both are reserved words for this I-D (this is why the capitalization is
handy.)  Without it (unless your very familiar with the document) its
hard to know what words have a particular defined meaning in the draft.

> f. Change "Posture Transport Clients" to "Posture Transport 
> Client" in section 5.1.1.3, first paragraph, last sentence.

Thanks

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Tue, 27 Feb 2007 13:56:04 -0800

Hi Mauricio,

Thanks for your comments. Please find my reply inline.

-----Original Message-----
From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
Sent: Sunday, February 25, 2007 6:25 PM
To: [email-masked]
Subject: [Nea] REQ: Section 5 comments

1.	Meta-comment: The model seems to assume that an endpoint
consists of
only one processing entity (OS, hardware, etc.).  It's unclear how the
model and the adjunct requirements may need to get modified in light of
rising popularity in system virtualization.  For example, it likely that
multiple posture broker clients and posture transport clients will exist
on single hardware system  that's been virtualized into multiple
systems. I'd say additional thought is necessary in this area or we just
punt and explicitly say that it's out of scope at this time.

<Kaushik> The endpoint necessarily translates to a single hardware
entity, the definition (host computing device) might be misleading and
will require some editing. The definition of the endpoint is actually in
terms how the network views the device, i.e. entities accessing the
network using different IP addresses. A virtualized system would
typically comprise of several endpoints.

2.	Meta-comment:  Section 9 describes several suggestions on how to
introduce user facilities to manage privacy.  In that section there's no
specific guidance on which components should implement the suggested
privacy enhancements.  If not in section 9, wouldn't it be useful to
assign the privacy enhancements to the model/components described in
section 5?  For example, I could envision seeing the posture collectors
and posture broker client sharing responsibilities in proving a user the
necessary UI and privacy policy management capabilities described in
section 9.  

<Kaushik> The privacy considerations largely focus on implementation
guidelines to address privacy concerns; the Reference Model is focussed
on the functional decomposition and it may not be right section to
introduce implementation considerations.

3.	Meta-comment:  The model describes the existence of protocols
between like layers (e.g. posture collector <--PA--> posture validator,
posture broker client <--PB--> posture broker server), but provides no
description as to what happens between different layers (posture
collector <-> posture broker).  I suspect that there's an unwritten
assumption that different layers may communicate using APIs.  If so, I
suggest that at a minimum there be some suggestion on how different
layers may be communicating (e.g. APIs) and noting that such work is out
of scope for the current WG charter (and IETF in general). 

Side note:  Section 5.1.2.2 states that validators may be physically
remote to the server.  Doesn't this particular situation give rise to
yet another
protocol for the NEA model to denote?   I can imagine the existence of a
PV
(Posture Validator) protocol between a remote posture validator and a
posture broker server.  Even though the current WG charter precludes
working on any protocol other than PA and PB, we should nonetheless
strive for completeness in the description of the model. 

4.	Meta-comment:  The document introduction (section 1.0) describes
the
existence of an enforcement entity to enforce the final admission
decision.
Although I understand that mechanisms and protocols for enforcement are
out of scope, shouldn't the NEA model diagram and description at least
acknowledge that an enforcement entity exists?  There should be a
general goal of having a comprehensive ENA model, even if complete
treatment of all components and protocols are not currently within NEA
charter.

<Kaushik> The above two items were deemed out-of-scope at the last IETF
as mentioned by Paul.

5.	Section 5.0: Discussion of reference model includes statement:
"This
model is provided to establish a context for the discussion of
requirements and may not directly map to any particular product or
deployment architecture." This statement seems to contradict the
statement made in the abstract that the NEA reference model is based on
the models used by CNAC, NAP and TNC.  

6.	Section 5.1.1.1, last paragraph:  From an interoperability
perspective NEA should evaluate mandating a minimum amount of
functionality
so as to improve the odds of interoperable implementations.   Or at a
minimum there should be some form of signaling introduced into the
protocol to provide for component capability advertisement. 

<Kaushik> I think plan was to define a core schema, i.e. a baseline set
of attributes that is mandatory to support for every NEA client/server.
Are you suggesting that protocol have some mechanism to advertise vendor
supported plugins to determine whether NEA client can interoperate with
the NEA server.

7.	Section 5.1.1.2, first paragraph, second sentence:
"...forwarding
the request to the appropriate Posture Collectors."  This sentence
sounds like a request always goes to multiple collectors.  I don't
believe this is always the case, or is it?  

8.	Section 5.1.1.2, first paragraph, third sentence: "The Posture
Broker Client also multiplexes the responses from the Posture
Collector..."
This sentence doesn't acknowledge that there may be one or more posture
collectors.  Consider changing to "...multiplexes the responses from
Posture Collector(s)..."

9.	Section 5.1.1.3 mentions that there may be more than one posture
transport client on an endpoint.  I suggest updating the diagram of the
model detailing this fact (e.g. add "(1...n)" to posture transport
client block as was done for posture collector).  Furthermore, it'd be
useful to describe why multiple transport clients may be necessary.  

10.	Section 5.1.2.1 mentions that a posture validator may be located
on
a separate server from the posture server.  It goes on to say that the
server may have to with both local and remote validators.  One can
assume that in the instance 

11.	Section 5.1.2.2 describes as one of the roles being,
"Communicating
with remote Posture Validators and providing cryptographic protection
for
this communication."   It's unclear to me what this exactly means.  The
broker server doesn't have any direct relationships with a posture
validator, or does it?  Furthermore, it's not clear at what level the
cryptographic protection is being provided.  In section 5.1.1.3 (about
posture transport client) it state clearly that its role is to protect
the message dialog.  I suggest the same level of clarity for server
broker's role.

<Kaushik> You are right.  This text is confusing since we are not
defining protocols between the Posture Broker Server and Posture
Validators. The cryptographic protection is actually provided by
encryption at the PA layer and not by the Posture Broker Server. I think
we can delete this sentence.

12.	Section 5.1.2.2 - Is it not the role of the posture broker
server to
also establish the overall compliance decision for an endpoint?
Currently the document only assigns the generation of the global posture
decision.  If not the broker server, which component generates the
overall compliance decision?  Or is the global posture decision in fact
the compliance decision?  I'm confused.

13.	Section 5.1.2.3 - Why may there be more than one posture
transport
server in a particular NEA server?  If there are truly multiple posture
transport servers, then the NEA model diagram should be updated to
reflect this possibility. See comment #8.

14.	Section 5.1.2.3 - The statement "Providing cryptographic
protection
for Posture information." is not as clear as the one used for the
posture transport client. For the posture transport client the described
role is protection of message dialog.  It's probably the same for the
transport server and should be designated as such in the document. 

15.	Section 5.3.1 - I sense there is at some level some relationship
between the attributes sent by a NEA server (i.e. requests) and those
sent by a NEA client (i.e. responses).  For example, isn't it the case
that request attributes always and only elicit posture attributes as a
response?
Likewise, couldn't the same be said of policy attributes and compliance
claim attributes?  If so, it may be useful to highlight these
relationships to make the protocol easier to understand. 

<Kaushik> Agree, as Paul pointed we will work to add this.

16.	Section 5.3.2 - It's unclear to me to what level the remediation
attributes will get defined.  On one hand the intro to this section
(5.3) states that NEA WG will define a standard set of attributes.  By
the same token other parts of the document (e.g. section 3.1 - scope)
state the
standard protocols for remediation are out of scope.   In defining
remediation attributes are we not inadvertently defining a standard
protocol for remediation? 

<Kaushik> Not really, we are merely providing a mechanism to carry
remediation instructions, for e.g. this may be a URL that might redirect
a client to a remediation server. The actual process & protocols for
remediation are still out of scope.

Regards,
  kaushik

NITS
a. Misplaced period in last sentence of section 5. [Reference model].
Period goes outside parenthesis bracket. 
b. Misplaced commas and periods in first sentence of 5.1.1.1 c.
Misplaced period in last sentence of second paragraph of section
5.1.1.1.
Same disposition as NIT 3a.
d. Missing period on second bullet of section 5.1.1.2 e. Why is Message
Dialog capitalized? See comment 7a.
f. Change "Posture Transport Clients" to "Posture Transport Client" in
section 5.1.1.3, first paragraph, last sentence.

916.785.1910 Tel
916.785.1815 Fax
[email-masked]