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

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

Title: Comments on NEA TNC PA & PB protocol specifications

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