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

[Kaushik Narayan <kaushik at cisco.com>]

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

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

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