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

From: "Paul Sangster" <[email-masked]>
Date: Thu, 5 Jun 2008 17:48:22 -0700

Kaushik,
 
Thanks for the comments, my responses are in-lined with [PS] prefix...

________________________________

	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
	
	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.
		 
		[PS] I agree we could use a design considerations
section to discuss how we got to the end design and how these issues
factored into the decision.  

	Some of the considerations have been called out in various
sections but it might help elevate that to the start of the document.
	 
	[PS] Agreed, many are discussed farther down in the spec, so we
could move up those that will help the reader understand the chosen
direction at a higher level before going into the design itself. 
	
	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. 
	 
	[PS] Would a high level example that ties into the protocol
flows help?  Maybe something like the use cases from the requirements
spec? Would you be willing to help contribute some text for this? 
	
	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.  
	 
	[PS] Ok. Generally the vendor ids are used to scope the
subsequent field where we want to allow either a standard value or a
vendor defined value to be present.  We could describe this in the
design considerations section (maybe you could provide some input into
that section as well). 
	
	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.
	 
	[PS] I believe we do call out encodings for text and binary in
the normative description of each field.  Did you have something else in
mind?
	 
	The specification does specify the definition of result or
assertion attributes.
	 
	[PS] I presume you mean it "... does not specify ..." These are
known open areas of the spec that require additional work that we had
hoped would occur in the NEA WG.  The original TNC spec does include
some examples of these types of attributes (e.g. "IMV Assessment
Results" and "Remediation Instructions" attributes) that we had hoped
would get some discussion in NEA before being added to the spec.  We
hope to discuss these types of attributes in Dublin.
	 
	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.
	 
	[PS] The vendor-id is needed in both the PB protocol and the PA
attributes.  In both cases it is scoping orthogonal fields.  You can
have PB vendor-id/subtype of IETF/Firewall containing PA attributes with
a mix of IETF (Product Information) and Vendor defined (stateful
inspection features) attributes.  You also could have a PB
vendor-id/subtype of Vendor/NFS Server containing PA attributes with a
mix of Vendor (kernel state) and IETF (String Version).   The 3 bytes is
the price we pay for this flexibility.
	
	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 ?
	 
	[PS] Yes and no (more the later :)).  It could be used for
multiple version of the same product but is more needed for when a
single collector is reporting on multiple products of the same type.
For instance, if Symantec and McAfee's anti-virus packages were both
installed on a system (one might be active and the other came with the
PC).  When an AV validator requests the Product Information and String
Version attributes for the IETF/AV component on the system, it would get
back 4 attributes (Product Information and String Version for each
installed AV product).  In order to deterministically correlate which
String Version goes with which Product Information attribute you would
need this ID.  Note that this is should not be very common case (single
posture collector knowing how to report posture on multiple existing
products) so normally these 4 bytes are not present.  The COR bit
indicates whether this field is present in the attribute header so there
is no wasted bits on the wire (besides the flag :)).
	
	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.
	 
	[PS] I believe the WG will need to define more of the attribute
and component type lists over time and the port filter attribute is a
good example of the more component specific type of attribute that might
be needed.  The goal is to build up a list over time of common
capabilities that might generically apply to a large number of OSes,
applications and environment so they can be included in a standard way
in an assessment.  This attribute allows an assessor to understand the
firewall policy being enforced on an endpoint as part of its assessment.
Without the attribute this couldn't be part of a standard assessment.
	
	PB protocol
	 
	[PS] I'll leave this to the PB editors

	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: Kaushik Narayan <[email-masked]>
Date: Fri, 06 Jun 2008 12:04:55 -0700

Hi Paul,

Please find response inline.

<snipped>
>> 
>> 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.
>> *  
>> * [PS] I  agree we could use a design considerations section to discuss how
>> we got to  the end design and how these issues factored into the decision.
>>  
> Some of the considerations have been called out in  various sections but it
> might help elevate that to the start of the  document.
>  
> [PS] Agreed, many are discussed farther down in the  spec, so we could move up
> those that will help the reader understand  the chosen direction at a higher
> level before going into the design  itself.
> 
> 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.
>  
> [PS] Would  a high level example that ties into the protocol flows help?
> Maybe  something like the use cases from the requirements spec? Would you be
> willing to help contribute some text for this?
> 
> 
> <Kaushik> I think it would be good to use se cases from the requirements
> document to illustrate the flows. I can help with drawing out the example
> flows </Kaushik>
> 
> 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.
>  
> [PS] Ok.  Generally the vendor ids are used to scope the subsequent field
> where  we want to allow either a standard value or a vendor defined value to
> be  present.  We could describe this in the design considerations section
> (maybe you could provide some input into that section as  well).
> 
> <Kaushik>  
> 
> I think it would be useful for the design considerations to cover
> 
> 1. Considerations for Independent Namespaces that amongst other things can
> highlight choices around vendor identification fields in various PA protocol
> headers. 
> 2. Considerations for extensibility and Scale to support dynamic addition of
> new vendor types and scale to a large number of vendor namespaces
> 3. Considerations for efficiency considerations for transport over low
> bandwidth links and processing on low horsepower devices (mobile)
> 4. Considerations for component typing and extensibility considerations.
> 5. Considerations for choice of attributes in the IETF vs Vendor specific
> namespaces for various components (AV, OS, Host FW etc.)
> 
> This might not be a complete list but can be used as a starting point. I can
> certainly help express these considerations from a requirements perspective, I
> will need your help to expand these considerations to include choices you made
> as part of protocol design & potentially co-relate the considerations to
> design decisions that are reflected in the PA protocol.
> 
> </Kaushik>
> 
> 
> 
> 
> 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.
>  
> [PS] I believe we do call out encodings for text and  binary in the normative
> description of each field.  Did you have  something else in mind?
> 
> 
> <Kaushik>
> 
> I was thinking of along the lines of the description of the attribute value
> field in the RADIUS RFC (RFC2865) copied below
> 
> From RFC2865 
> 
> ³Value
> 
>       The Value field is zero or more octets and contains information
>       specific to the Attribute.  The format and length of the Value
>       field is determined by the Type and Length fields.
> 
>       Note that none of the types in RADIUS terminate with a NUL (hex
>       00).  In particular, types "text" and "string" in RADIUS do not
>       terminate with a NUL (hex 00).  The Attribute has a length field
>       and does not use a terminator.  Text contains UTF-8 encoded 10646
>       [7] characters and String contains 8-bit binary data.  Servers and
>       servers and clients MUST be able to deal with embedded nulls.
>       RADIUS implementers using C are cautioned not to use strcpy() when
>       handling strings.
> 
>       The format of the value field is one of five data types.  Note
>       that type "text" is a subset of type "string".
> 
>       text      1-253 octets containing UTF-8 encoded 10646 [7]
>                 characters.  Text of length zero (0) MUST NOT be sent;
>                 omit the entire attribute instead.
> 
>       string    1-253 octets containing binary data (values 0 through
>                 255 decimal, inclusive).  Strings of length zero (0)
>                 MUST NOT be sent; omit the entire attribute instead.
> 
>       address   32 bit value, most significant octet first.
> 
>       integer   32 bit unsigned value, most significant octet first.
> 
>       time      32 bit unsigned value, most significant octet first --
>                 seconds since 00:00:00 UTC, January 1, 1970.  The
>                 standard Attributes do not use this data type but it is
>                 presented here for possible use in future attributes.²
> 
> 
> regards,
>  kaushik
> 
> </Kaushik>
> 
> The specification does  specify the definition of result or assertion
> attributes.
>  
> [PS] I presume you mean it "... does not specify  ..." These are known open
> areas of the spec that require  additional work that we had hoped would occur
> in the NEA WG.  The  original TNC spec does include some examples of these
> types of attributes  (e.g. "IMV Assessment Results" and "Remediation
> Instructions" attributes)  that we had hoped would get some discussion in NEA
> before being added to the  spec.  We hope to discuss these types of attributes
> in  Dublin.
>  
> 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.
>  
> [PS] The  vendor-id is needed in both the PB protocol and the PA  attributes.
> In both cases it is scoping orthogonal fields.   You can have PB
> vendor-id/subtype of IETF/Firewall containing PA  attributes with a mix of
> IETF (Product Information) and Vendor defined  (stateful inspection features)
> attributes.  You also could have a PB  vendor-id/subtype of Vendor/NFS Server
> containing PA attributes with a mix  of Vendor (kernel state) and IETF (String
> Version).   The 3  bytes is the price we pay for this flexibility.
> 
> 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 ?
>  
> [PS] Yes  and no (more the later :)).  It could be used for multiple version
> of the  same product but is more needed for when a single collector is
> reporting  on multiple products of the same type.  For instance, if Symantec
> and McAfee's anti-virus packages were both installed on a system (one might be
> active and the other came with the PC).  When an AV validator requests  the
> Product Information and String Version attributes for the IETF/AV  component
> on the system, it would get back 4 attributes (Product  Information and String
> Version for each installed AV product).  In order  to deterministically
> correlate which String Version goes with which Product  Information attribute
> you would need this ID.  Note that this is should  not be very common case
> (single posture collector knowing how to report  posture on multiple existing
> products) so normally these 4 bytes are not  present.  The COR bit indicates
> whether this field is present in the  attribute header so there is no wasted
> bits on the wire (besides the flag  :)).
> 
> 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.
>  
> [PS] I believe the WG will need to define more  of the attribute and component
> type lists over time and the port filter  attribute is a good example of the
> more component specific type of attribute  that might be needed.  The goal is
> to build up a list over time  of common capabilities that might generically
> apply to a large number of OSes,  applications and environment so they can be
> included in a standard way in an  assessment.  This attribute allows an
> assessor to understand the firewall  policy being enforced on an endpoint as
> part of its assessment.  Without  the attribute this couldn't be part of a
> standard  assessment.
> 
> 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: "Stephen Hanna" <[email-masked]>
Date: Fri, 6 Jun 2008 17:44:15 -0400

Let me speak up on the issues relevant to PB-TNC in Kaushik's email.
I'll mark my comments with [SH] below and snip out the sections that
pertain to PA-TNC.
 
Thanks,
 
Steve

		*	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. 
		*	
		*	[PS] I  agree we could use a design
considerations section to discuss how we got to  the end design and how
these issues factored into the decision.   
			[SH] Yes, this would be useful for PB-TNC also.
I'm willing to draft something for PB-TNC.

	

	<Kaushik> I think it would be good to use se cases from the
requirements document to illustrate the flows. I can help with drawing
out the example flows </Kaushik>
	 
	[SH] Are you willing to do this for PB-TNC also?
	 
	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.  

	<Kaushik>  
	
	I think it would be useful for the design considerations to
cover

	1.	Considerations for Independent Namespaces that amongst
other things can highlight choices around vendor identification fields
in various PA protocol headers. 
	2.	Considerations for extensibility and Scale to support
dynamic addition of new vendor types and scale to a large number of
vendor namespaces 
	3.	Considerations for efficiency considerations for
transport over low bandwidth links and processing on low horsepower
devices (mobile) 
	4.	Considerations for component typing and extensibility
considerations. 
	5.	Considerations for choice of attributes in the IETF vs
Vendor specific namespaces for various components (AV, OS, Host FW etc.)

	This might not be a complete list but can be used as a starting
point. I can certainly help express these considerations from a
requirements perspective, I will need your help to expand these
considerations to include choices you made as part of protocol design &
potentially co-relate the considerations to design decisions that are
reflected in the PA protocol.
	
	</Kaushik>
	
	 [SH] As noted above, I'd be glad to work on something similar
with you for PB-TNC.
	
	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. 
	 
	[SH] Maybe this change would be helpful. I'm afraid we would end
up with a similar problem: layers of different attributes (vs.
messages).

	[SH] We weren't trying to support multiple PBCs or PBSs on one
device. We just wanted to allow vendors to create extensions in a
compatible and standardized manner.

	[SH] Yes, a table is a good idea. 
	 
	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.
	
	 [SH] As currently defined, PB-TNC is a half-duplex protocol.
While this is necessary when the underlying transport is half-duplex
(EAP, for example), it is not necessary when the transport is
full-duplex. I suggest that we explore ways to ameliorate this problem.
For example, we should allow PB-TNC to take advantage of full-duplex
transports but still ensure that it functions over half-duplex
transports. We can't really just leave the behavior open to
implementations. That won't get us to interoperability.

---

From: Kaushik Narayan <[email-masked]>
Date: Sat, 07 Jun 2008 21:35:34 -0700

Hi Steve,

Thanks for your response. Please find my response inline tagged
<Kaushik-Response>

>>> * [SH] Yes, this would be useful for  PB-TNC also. I'm willing to draft
>>> something for  PB-TNC.
>>  
>> [PS] Agreed, many are discussed farther  down in the  spec, so we could move
>> up those that will help the reader  understand  the chosen direction at a
>> higher level before going into the  design  itself.
>> 
>> evaluate  various protocol specifics such  as structuring of various headers
>> or  presence  of certain fields in  certain headers.
>> 
>> <Kaushik-Response>
>> Sure. I can take a crack at that; the flows will need to encompass both PA
>> and PB protocol. I will try to pick use cases that exemplify PA and PB
>> aspects to include in the respective protocol specifications.
>> 
>> </Kaushik-Response>
>> 
>> 
>>  
>>  
> certainly help express these  considerations from a requirements perspective,
> I will need your help to  expand these considerations to include choices you
> made as part of protocol  design & potentially co-relate the considerations to
>  [SH] As noted above, I'd be glad  to work on something similar with you for
> PB-TNC.
> 
> <Kaushik-Response>
> 
> That sounds good.
> 
> </Kaushik-Response>
> 
> 
> 
> 
> PB protocol
> 
> [SH] Maybe this  change would be helpful. I'm afraid we would end up with a
> similar  problem: layers of different attributes (vs.  messages).
> 
> 
> <Kaushik-Response>
> 
> I am not sure that there is a difference between attributes at the PA vs PB
> layers, they are just TLVs and in some cases might be similar in nature, for
> e.g. Posture assessment result at the PA layer and the global assessment
> result at the PB layer.
> 
> </Kaushik-Response>
> 
> 
> 
> [SH] We weren't  trying to support multiple PBCs or PBSs on one device. We
> just wanted to allow  vendors to create extensions in a compatible and
> standardized  manner.
> 
> <Kaushik-Response>
> 
> I think it might be helpful to articulate with examples the use of the
> vendor-id at the PB layer and the nature of such extensions.
> 
> </Kaushik-Response>
> 
> 
> 
> 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
>  [SH] As currently defined, PB-TNC is a half-duplex  protocol. While this is
> necessary when the underlying transport is  half-duplex (EAP, for example), it
> is not necessary when the transport is  full-duplex. I suggest that we explore
> ways to ameliorate this problem. For  example, we should allow PB-TNC to take
> advantage of full-duplex  transports but still ensure that it functions over
> half-duplex  transports. We can't really just leave the behavior open to
> <Kaushik-Response>
> Were you thinking about including an initial proposal/options of addressing
> this in the next revision  ?
> 
> regards,
>  kaushik
> 
> </Kaushik-Response>
>  
>  
>

---

From: "Stephen Hanna" <[email-masked]>
Date: Sun, 8 Jun 2008 07:21:26 -0400

Thanks, Kaushik. My responses below are marked [SH2]. To be honest, I
must say that I find this tagging mechanism more difficult to follow
than the old practice of using "> " in a plain text email. But here we
are in an HTML thread so I will continue in kind. I will remove as much
text as I can so we can focus on the few remaining open issues.
 
Thanks,
 
Steve

From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Sunday, June 08, 2008 12:36 AM
To: Stephen Hanna; Paul Sangster; [email-masked]
Subject: Re: [Nea] Comments on NEA TNC PA & PB protocol specifications

Hi Steve,

	<snipped>

		[PS] Would  a high level  example that ties into the
protocol flows help?  Maybe  something  like the use cases from the
requirements spec? Would you be  willing to  help contribute some text
for this? 
		
		<Kaushik> I think it would  be good to use se cases from
the requirements document to illustrate the  flows. I can help with
drawing out the example flows </Kaushik>

		<Kaushik-Response>
		
		Sure. I can take a crack at that; the flows will need to
encompass both PA and PB protocol. I will try to pick use cases that
exemplify PA and PB aspects to include in the respective protocol
specifications.
		
		</Kaushik-Response>
		
		 [SH2]  Great! Thanks for volunteering for this task.

	PB protocol

	[SH] Maybe this  change would be helpful. I'm afraid we would
end up with a similar  problem: layers of different attributes (vs.
messages).
	
	 <Kaushik-Response>
	
	I am not sure that there is a difference between attributes at
the PA vs PB layers, they are just TLVs and in some cases might be
similar in nature, for e.g. Posture assessment result at the PA layer
and the global assessment result at the PB layer. 
	
	</Kaushik-Response>
	 
	[SH2] We used the term "message" for the outermost component of
a particular protocol. Since this is only a wording change and there are
lots of other changes coming in -01, I suggest that we set aside this
matter and revisit it when -01 has been published. We can ask WG
participants to weigh in with an opinion on this after they review -01.
It shouldn't be hard to make the change if that's WG consensus.

	
	<Kaushik-Response>
	
	I think it might be helpful to articulate with examples the use
of the vendor-id at the PB layer and the nature of such extensions.
	
	</Kaushik-Response>
	
	[SH2] Good idea. I'll plan to add this in -01. 

	<Kaushik-Response>
	
	Were you thinking about including an initial proposal/options of
addressing this in the next revision  ?
	
	regards,
	 kaushik
	
	</Kaushik-Response>
	
	 [SH2] Yes, let's try to address this in -01. Let me start a
separate thread on this topic.