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

["Stephen Hanna" <shanna at juniper.net>]

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

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:kaushik at cisco.com]
Sent: Friday, March 07, 2008 11:10 AM
To: Stephen Hanna
Cc: nea at ietf.org
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




On 3/7/08 9:15 AM, 
"Stephen Hanna" <shanna at juniper.net> wrote:

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: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Kaushik Narayan
Sent: Friday, March 07, 2008 8:15 AM
To: nea at ietf.org
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.
  

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
Nea at ietf.org
https://www.ietf.org/mailman/listinfo/nea