Subject: RE: [Nea] REQ: Section 5 comments

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 5 Mar 2007 06:47:13 -0000

Paul wrote...

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

So it sounds like you're of the mindset that this topic should be visited in
the future rather than immediately punting. Who's keeping track of what
things we need to track back on in the future?  We should add virtualization
to that list. 

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

In section 8.1.1 there's the statement, "The NEA Reference Model assumes all
the NEA Client components are local to the Endpoint and communicate over
local API or program calls."  Doesn't this contradict you. 

> > 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.
> 
> 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]?)

It sounds like a bit of a quagmire.  If the model is untouchable, then the
only option you have is to patch it with text in the sections you mention.  

BTW, were remote PV's considered during the development of the model?  If so
and they were left out intentionally, one could be dogmatic and say that
remote PV's are prohibited (or at least out of scope) and your security
mileage will vary with them present. 

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

But by the same token you have section 8.1.2 describing them. 

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

Yes.  But the opposite may also be true, whereby a posture collector
supports a limited set of attributes.  How does the posture validator know
what the posture collector does or doesn't support?

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

Both.
 
> 
> >
> > 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?
> 
> No its based upon which Posture Collectors are involved (requested to
> be) in the assessment.  Will clean-up the text to help.

Ok.

> 
> >
> > 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
> 
> I can't parse this ...

This was a test to see whether you checked every comment.  You passed.
Actually, it's a comment I failed to finish before sending the email.  I
can't remember what I was thinking about for this comment, but it may come
back later.  

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

I agree with removing it.  It just detracts. 

> 
> >
> > 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.
> 
> Global posture decision == overall compliance decision
> 
> We don't use the expression "overall compliance decision"

Ah, I see. 

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

Ok.

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

Ok. 

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

The creation of the remediation attribute category but no standardizing
within the category is an important point that should be highlighted in the
document. 

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

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 5 Mar 2007 20:39:22 -0800

Comments below... 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, March 04, 2007 10:47 PM
> To: Paul Sangster; [email-masked]
> Subject: RE: [Nea] REQ: Section 5 comments
> 
> 
> Paul wrote...
> 
> > 
> > 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
> > Posture about the hypervisor layer but this could be addressed in 
> > different ways.
> > 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.
> 
> So it sounds like you're of the mindset that this topic 
> should be visited in the future rather than immediately 
> punting. Who's keeping track of what things we need to track 
> back on in the future?  We should add virtualization to that list. 

Now that -01 is published it's a fine time to discuss this topic so this
topic has been separated from the prior thread in hopes of giving it
more attention from the WG.  Can you explain more about the
virtualization model you had in mind and how it might impact the spec?

<snip>

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 5 Mar 2007 21:04:06 -0800

Comments below...

<snip>

> > > 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).
> > 
> > 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.
> 
> In section 8.1.1 there's the statement, "The NEA Reference 
> Model assumes all the NEA Client components are local to the 
> Endpoint and communicate over local API or program calls."  
> Doesn't this contradict you. 

Apparently so :).  We'll consider removing the "and communicate ..."
phrase.  *If* we're going to add the text you suggest it should probably
be in the Reference Model section.

> physically 
> > > remote to the server.  Doesn't this particular situation 
> give rise 
> > > to yet another
> 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.
> > 
> > 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.
> > why a deployer might wish to use strong security 
> protections on the PA 
> It sounds like a bit of a quagmire.  If the model is 
> untouchable, then the only option you have is to patch it 
> with text in the sections you mention.  
> 
> BTW, were remote PV's considered during the development of 
> the model?  If so and they were left out intentionally, one 
> could be dogmatic and say that remote PV's are prohibited (or 
> at least out of scope) and your security mileage will vary 
> with them present. 

Yes their was a lot of discussion about the PV protocol during the early
days of NEA but it was deemed out of scope.  This might be something to
consider addressing after the WG meets all our chartered set of
milestones.

Depending on how the WG feels about the remote PV topic we might remove
all mentions of it from the draft (or if the chair's want to declare it
in scope ...)

> But by the same token you have section 8.1.2 describing them. 

What is out of scope is the NEA protocols to/from the enforcement
devices.  This section merely discusses that network devices could
impact the security of the NEA protocols so should be considered.

> into the 
> > > protocol to provide for component capability advertisement.
> > 
> Yes.  But the opposite may also be true, whereby a posture 
> collector supports a limited set of attributes.  How does the 
> posture validator know what the posture collector does or 
> doesn't support?

I'd be interested in hearing other folks opinion on this as I think this
reasoning makes sense.  However, I've heard the argument that their will
be a core (standard) set of Attributes that MUST be supported so this is
really more towards the vendor specific where Attributes might not be
supported (and thus potentially not interesting to define).  This
argument implies that we won't have any Attributes that are
syntactically defined yet are a MAY or SHOULD to implement (I could
envision this happening for some attributes that support a particular
usage model like the Compliance Claim Attributes).  

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

Ok, this warrents a discussion.

<Removing areas of agreement ... snip>

> > > 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?
> > 
> > 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.
> >
> 
> The creation of the remediation attribute category but no 
> standardizing within the category is an important point that 
> should be highlighted in the document. 

Ok, we'll look to add alittle text on this.