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
