- 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?
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
- Considerations for Independent Namespaces that amongst other
things can highlight choices around vendor identification fields in various
PA protocol headers.
- Considerations for extensibility and Scale to support dynamic
addition of new vendor types and scale to a large number of vendor
namespaces
- Considerations for efficiency
considerations for transport over low bandwidth links and processing on low
horsepower devices (mobile)
- Considerations for component typing
and extensibility considerations.
- 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.
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).
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.
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.
