Re: [Nea] Comments on NEA TNC PA & PB protocol specifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

That sounds reasonable.

Regards,
 kaushik

On 3/7/08 11:45 AM, "Stephen Hanna" <shanna at juniper.net> 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

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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.