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

Thanks for your response. Please find my response inline tagged <Kaushik-Response>

<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.   
• [SH] Yes, this would be useful for  PB-TNC also. I'm willing to draft something for  PB-TNC.
  

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>
 

[SH] Are you willing to do this for PB-TNC  also?


<Kaushik-Response>

Sure. I can take a crack at that; the flows will need to encompass both PA and PB protocol. I will try to pick use cases that exemplify PA and PB aspects to include in the respective protocol specifications.

</Kaushik-Response>


 

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>

 [SH] As noted above, I'd be glad  to work on something similar with you for  PB-TNC.

<Kaushik-Response>

That sounds good.

</Kaushik-Response>




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.

 
 
[SH] Maybe this  change would be helpful. I'm afraid we would end up with a similar  problem: layers of different attributes (vs.  messages).


<Kaushik-Response>

I am not sure that there is a difference between attributes at the PA vs PB layers, they are just TLVs and in some cases might be similar in nature, for e.g. Posture assessment result at the PA layer and the global assessment result at the PB layer.

</Kaushik-Response>



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.

 
 
[SH] We weren't  trying to support multiple PBCs or PBSs on one device. We just wanted to allow  vendors to create extensions in a compatible and standardized  manner.

<Kaushik-Response>

I think it might be helpful to articulate with examples the use of the vendor-id at the PB layer and the nature of such extensions.

</Kaushik-Response>



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.

 
 
[SH] Yes, a  table is a good idea.
 
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.

[SH] As currently defined, PB-TNC is a half-duplex  protocol. While this is necessary when the underlying transport is  half-duplex (EAP, for example), it is not necessary when the transport is  full-duplex. I suggest that we explore ways to ameliorate this problem. For  example, we should allow PB-TNC to take advantage of full-duplex  transports but still ensure that it functions over half-duplex  transports. We can't really just leave the behavior open to implementations.  That won't get us to interoperability.


<Kaushik-Response>

Were you thinking about including an initial proposal/options of addressing this in the next revision  ?

regards,
 kaushik

</Kaushik-Response>

 

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www.ietf.org/mailman/listinfo/nea