[Nea] Comments on draft-sahita-nea-pb-tnc-00.txt

[Gary Tomlinson <gtomlinson at SonicWALL.com>]

The following comments are regarding the individual submission
draft-sahita-nea-pb-tnc-00.txt of a PB protocol for consideration by the NEA
working group as a base to develop the PB protocol from.

First, an overall comment is this is a very well written document and in my
opinion should be be strongly considered by the WG as its scope covers all
of the PB requirements specified to date.

Of course I do have some specific comments.  Here they are:

Page 12, section 3.2. PB-TNC Message Length description, last sentence ...
SHOULD send an Invalid Parameter ...  For a protocol violation, why is this
a SHOULD and not a MUST?

Page 19,  section 3.6.Posture Collector Identifier.  My first reaction to
this being assigned by the Posture Broker Client as a local node scoped
address was how can a Posture Broker Server know how to discover it in order
to initiate a message to it.  Upon reviewing the PA-TNC protocol submission
I learned a PA Attribute Request addressed to ANY Posture Collector of a PA
subtype can be used to discover specific Posture Collector Identifiers.
Since I was unable to derive this strictly from the PB-TNC draft, it occurs
to me some clarification might be in order that states the dependence upon
the PA protocol for discovery of Posture Collector Identifiers by Posture
Server Brokers/Validators.

Page 20, section 3.6. PN-TNC Posture Validator Identifier.  This is
essentially the same comment as I made regarding the Posture Collector
Identifier but from the inverse relationship of the Posture Broker Client
discovering specific Posture Validators; however I was unable to derive a
condoned method since PA-TNC Attribute Requests aren't supposed to be sent
by Posture Collectors except for PA-TNC Security crypto algorithm support
discovery.  With this in mind, how can a Posture Broker Client direct a
message to a specific Posture Validotor without having had previous
communication with it?

Page 22, section 3.7 Access Recommendation code.  For the access code value
Access Allowed=1, I was unable to determine in the protocol at large how to
support the reassessment use case where the Posture Broker Server needs to
control the reassessment interval but can't initiate a new connection to
restart the state machine.  This is a common problem when TLS is used as PT
and intermediary security devices such as firewalls and NATs block
connections to the end point device. One new solution that occurred to me
was the reserved field could become a flags field with a reassessment flag
bit and an additional 32 bit field could be added with the number of seconds
until a reassessment is required.  The reassessment bit if set would enable
the value in the reassessment field to be used by the Posture Broker Client
to initiate a new assessment sequence.  This capability would also address
the reassessment points made on page 35 section 4.2.

Page 25, Section 3.8 Remediation Parameters last paragraph.  The ambiguity
faced with a protocol error needs to be resolved.  I would argue that a
malformed RESULT message from the Posture Server Broker doesn't constitute a
proper transition to the DECIDED state and that we need the capability to
issue a Parameter Error message as reply to any transition in the state
machine and transition back to the callers previous state.

Page 38, section 4.11.  In addition to carrying attributes, PB-TNC provides
explicit attribute support for posture decision and remediation aid
notification.

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