Subject: [Nea] Comments on NEA TNC PA & PB protocol specifications

From: Kaushik Narayan <[email-masked]>
Date: Fri, 07 Mar 2008 08:14:31 -0800

Here are my comments on the NEA TNC PA & PB protocol specifications

Overall (This applies to both PA & PB protocol specifications)

It might be useful to have a section that describes any protocol design
considerations above and beyond the NEA Reference model; some examples of
such considerations could include
* Motivation for signaling state transitions over-the-wire using PB batch
messages. 
* PA Message Delivery/Routing   subscription & explicit identification
* Design considerations for performance, scale & extensibility 
optimization of round trips, PA/PB protocol header overhead, vendor
identification included in various PB & PA message/attribute headers.
Some of the considerations have been called out in various sections but it
might help elevate that to the start of the document.

Lack of packet processing details or protocol flows makes it difficult to
evaluate various protocol specifics such as structuring of various headers
or presence  of certain fields in certain headers.

The description for some of the common fields in various protocol headers
such as vendor-id  has common text but does not specify why that field is
present in that specific header.

PA Protocol

A syntax for the attributes needs to be defined; it is necessary to explain
how various types of text and binary data will by represented.
 
The specification does specify the definition of result or assertion
attributes.
 
There is vendor-id field in the Attribute header but I am not sure whether
this vendor-id needs to be carried over-the-wire for every attribute since
this vendor-id is not expected to be different from the vendor-id in the
PB-PA message. Is there a reason to have vendor-id inside each attribute ? I
would recommend removing the vendor-id from the attribute if it is not
needed since it will save 3 bytes of data per attribute and that can be
significant in an assessment that involves a large number of attributes.

The need for co-relation id is not very clear since in most cases products
should be differentiated using PA message type, i.e. Component type + vendor
id. Is this to handle the case where different versions of the same product
are installed on the endpoint ?

The ³port filter² seems to be an odd attribute to include in the standard
schema, the rest of the attributes seem to be associated with general
OS+application information whereas port filter seems like an attribute
associated with a  specific component.

PB protocol

The term ³message² used to represent various PB layer attributes is very
confusing; wondering why we can¹t use the term ³attribute²  since that term
is already used within the NEA Reference model to represent PB layer
information.

The use of PB vendor id is not clear since the NEA Reference model does not
describe behavior with multiple posture broker client(s)/server(s), not sure
how vendor specific message types at the PB layer will be handled.

It is not clear which PB message types will processed by the PB Client or
Server whilst in different states described in Section 2.2. A table
summarizing the various states and messages that can be received in that
state would be helpful.
 
The need to create a new PT connection if the server is required to send a
SDATA after the server has sent a RESULT as described at the end of Section
2.2. seems like an artificial limitation placed. This behavior should be
left open to implementations so that they can optimize in case a PT is more
capable than just a half-duplex behavior.

regards,
 kaushik

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 7 Mar 2008 12:15:28 -0500

Thanks for sending these comments, Kaushik. They are quite valuable and
certainly can be addressed. I'm sure there will be a good discussion of
them on the NEA list once a decision has been made about whether to
adopt the documents as WG specs. However, Susan and I have asked for
discussion now to focus on whether the documents should become WG specs.
I don't think you expressed an opinion on that topic. Do you have one?
If so, could you send it to the NEA list?
 
Thanks,
 
Steve

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kaushik Narayan
Sent: Friday, March 07, 2008 8:15 AM
To: [email-masked]
Subject: [Nea] Comments on NEA TNC PA & PB protocol specifications

It might be useful to have a section that describes any protocol design
considerations above and beyond the NEA Reference model; some examples
of such considerations could include 

*	Motivation for signaling state transitions over-the-wire using
PB batch messages. 
*	PA Message Delivery/Routing -  subscription & explicit
identification 
*	Design considerations for performance, scale & extensibility -
optimization of round trips, PA/PB protocol header overhead, vendor
identification included in various PB & PA message/attribute headers.

Some of the considerations have been called out in various sections but
it might help elevate that to the start of the document.

Lack of packet processing details or protocol flows makes it difficult
to evaluate various protocol specifics such as structuring of various
headers or presence  of certain fields in certain headers. 

The description for some of the common fields in various protocol
headers such as vendor-id  has common text but does not specify why that
field is present in that specific header.  

PA Protocol

A syntax for the attributes needs to be defined; it is necessary to
explain how various types of text and binary data will by represented.

There is vendor-id field in the Attribute header but I am not sure
whether this vendor-id needs to be carried over-the-wire for every
attribute since this vendor-id is not expected to be different from the
vendor-id in the PB-PA message. Is there a reason to have vendor-id
inside each attribute ? I would recommend removing the vendor-id from
the attribute if it is not needed since it will save 3 bytes of data per
attribute and that can be significant in an assessment that involves a
large number of attributes.

The need for co-relation id is not very clear since in most cases
products should be differentiated using PA message type, i.e. Component
type + vendor id. Is this to handle the case where different versions of
the same product are installed on the endpoint ?

The "port filter" seems to be an odd attribute to include in the
standard schema, the rest of the attributes seem to be associated with
general OS+application information whereas port filter seems like an
attribute associated with a  specific component.

PB protocol

The term "message" used to represent various PB layer attributes is very
confusing; wondering why we can't use the term "attribute"  since that
term is already used within the NEA Reference model to represent PB
layer information.

The use of PB vendor id is not clear since the NEA Reference model does
not describe behavior with multiple posture broker client(s)/server(s),
not sure how vendor specific message types at the PB layer will be
handled.

It is not clear which PB message types will processed by the PB Client
or Server whilst in different states described in Section 2.2. A table
summarizing the various states and messages that can be received in that
state would be helpful.
 
The need to create a new PT connection if the server is required to send
a SDATA after the server has sent a RESULT as described at the end of
Section 2.2. seems like an artificial limitation placed. This behavior
should be left open to implementations so that they can optimize in case
a PT is more capable than just a half-duplex behavior.

regards,
 kaushik

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 07 Mar 2008 11:10:25 -0800

Hi Steve,

I think we can accept the NEA TNC PA & PB protocol specifications as WG
specifications assuming that the issues raised below will be addressed once
these specifications are adopted by the WG.

regards,
 kaushik

On 3/7/08 9:15 AM, "Stephen Hanna" <[email-masked]> wrote:

> certainly can be addressed. I'm sure there will be a good discussion of them
> on the NEA list once a decision has been made about whether to adopt the
> documents as WG specs. However, Susan and I have asked for discussion now to
> focus on whether the documents should become WG specs. I don't think you
> expressed an opinion on that topic. Do you have one? If so, could you send it
> to the NEA list?
>  
> Thanks,
>  
> Steve
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Kaushik
> Narayan
> considerations above and beyond the NEA Reference model; some examples of such
> considerations could include
> * Design considerations for performance, scale &  extensibility  optimization
> of round trips, PA/PB protocol header overhead,  vendor identification
> included in various PB & PA message/attribute  headers.
> evaluate various protocol specifics such as structuring of various headers or
> presence  of certain fields in certain headers.
> 
> The description for some of the common fields in various protocol headers such
> as vendor-id  has common text but does not specify why that field is present
> in that specific header.
> 
> PA Protocol
> 
> this vendor-id is not expected to be different from the vendor-id in the PB-PA
> message. Is there a reason to have vendor-id inside each attribute ? I would
> recommend removing the vendor-id from the attribute if it is not needed since
> it will save 3 bytes of data per attribute and that can be significant in an
> assessment that involves a large number of attributes.
> 
> confusing; wondering why we can¹t use the term ³attribute²  since that term is
> already used within the NEA Reference model to represent PB layer information.
> 
> summarizing the various states and messages that can be received in that state
> would be helpful.
>  
> 2.2. seems like an artificial limitation placed. This behavior should be left
> open to implementations so that they can optimize in case a PT is more capable
> than just a half-duplex behavior.
> 
> regards,
>  kaushik
> 
> 
> 
> 
> 
> 
>

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 7 Mar 2008 14:45:31 -0500

Thanks for your response. If these become WG drafts, all decisions about
what to change will be made by WG consensus, as is typical for IETF. I
can't promise what the WG will decide on any of the items that you
raised but they all seem to me to be very reasonable. I would expect
them to be addressed in some manner.
 
Take care,
 
Steve

From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 11:10 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Nea] Comments on NEA TNC PA & PB protocol specifications

Hi Steve,

I think we can accept the NEA TNC PA & PB protocol specifications as WG
specifications assuming that the issues raised below will be addressed
once these specifications are adopted by the WG.

regards,
 kaushik

	Thanks for sending these comments, Kaushik. They are quite
valuable and certainly can be addressed. I'm sure there will be a good
discussion of them on the NEA list once a decision has been made about
whether to adopt the documents as WG specs. However, Susan and I have
asked for discussion now to focus on whether the documents should become
WG specs. I don't think you expressed an opinion on that topic. Do you
have one? If so, could you send it to the NEA list?
	
	Thanks,
	
	Steve

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kaushik Narayan
	Sent: Friday, March 07, 2008 8:15 AM
	To: [email-masked]
	Subject: [Nea] Comments on NEA TNC PA & PB protocol
specifications

	Here are my comments on the NEA TNC PA & PB protocol
specifications

	It might be useful to have a section that describes any protocol
design considerations above and beyond the NEA Reference model; some
examples of such considerations could include 

	*	Motivation for signaling state transitions
over-the-wire using PB batch messages.   
	*	PA  Message Delivery/Routing -  subscription & explicit
identification    
	*	Design considerations for performance, scale &
extensibility - optimization of round trips, PA/PB protocol header
overhead,  vendor identification included in various PB & PA
message/attribute  headers.

	Some of the considerations have been called out in various
sections but it might help elevate that to the start of the document.
	
	Lack of packet processing details or protocol flows makes it
difficult to evaluate various protocol specifics such as structuring of
various headers or presence  of certain fields in certain headers. 
	
	The description for some of the common fields in various
protocol headers such as vendor-id  has common text but does not specify
why that field is present in that specific header.  
	
	PA Protocol
	
	A syntax for the attributes needs to be defined; it is necessary
to explain how various types of text and binary data will by
represented.
	 
	The specification does specify the definition of result or
assertion attributes.
	 
	There is vendor-id field in the Attribute header but I am not
sure whether this vendor-id needs to be carried over-the-wire for every
attribute since this vendor-id is not expected to be different from the
vendor-id in the PB-PA message. Is there a reason to have vendor-id
inside each attribute ? I would recommend removing the vendor-id from
the attribute if it is not needed since it will save 3 bytes of data per
attribute and that can be significant in an assessment that involves a
large number of attributes.
	
	The need for co-relation id is not very clear since in most
cases products should be differentiated using PA message type, i.e.
Component type + vendor id. Is this to handle the case where different
versions of the same product are installed on the endpoint ?

	PB protocol
	
	The term "message" used to represent various PB layer attributes
is very confusing; wondering why we can't use the term "attribute"
since that term is already used within the NEA Reference model to
represent PB layer information.
	
	The use of PB vendor id is not clear since the NEA Reference
model does not describe behavior with multiple posture broker
client(s)/server(s), not sure how vendor specific message types at the
PB layer will be handled.
	
	It is not clear which PB message types will processed by the PB
Client or Server whilst in different states described in Section 2.2. A
table summarizing the various states and messages that can be received
in that state would be helpful.
	 
	The need to create a new PT connection if the server is required
to send a SDATA after the server has sent a RESULT as described at the
end of Section 2.2. seems like an artificial limitation placed. This
behavior should be left open to implementations so that they can
optimize in case a PT is more capable than just a half-duplex behavior.
	
	regards,
	 kaushik

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 07 Mar 2008 11:53:51 -0800

Hi Steve,

That sounds reasonable.

Regards,
 kaushik

On 3/7/08 11:45 AM, "Stephen Hanna" <[email-masked]> wrote:

> Thanks for your response. If these become WG drafts, all decisions about what
> to change will be made by WG consensus, as is typical for IETF. I can't
> promise what the WG will decide on any of the items that you raised but they
> all seem to me to be very reasonable. I would expect them to be addressed in
> some manner.
>  
> Take care,
>  
> Steve
> 
>