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

["Sahita, Ravi" <ravi.sahita at intel.com>]

Thanks to Gary for his detailed review and comments on the PB-TNC draft
- 
I have some replies inline prefixed by Ravi>

Regards,
Ravi

-----Original Message-----
From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of
Gary Tomlinson
Sent: Thursday, February 28, 2008 4:25 PM
To: nea at ietf.org
Subject: [Nea] Comments on draft-sahita-nea-pb-tnc-00.txt

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.

Ravi> Thanks!


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?

Ravi> Agree - this will be changed to 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.

Ravi> The assumption here is that, the PB Client assigns the unique
Posture Collector Identifiers (PCI) and the PB server assigns the unique
Posture Validator Identifiers (PVI) to be able to multiplex and
de-multiplex messages that are exclusively meant for specific Posture
Collectors or Posture Validators. In the case you mentioned, where the
PB server sends the initial message, the expected behavior is that the
PB server will use the standard PA Message Vendor ID (0) and all f's PCI
to route PA-attribute request messages to the Posture Collectors, and
the Collectors that provide the requested posture information will
respond, which the PB Client will package with the currently allocated
PCIs. After this response the PB server can name the appropriate PCI as
required.



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?

Ravi> The PA vendor Id could always be used to route information to a
specific vendors Posture Validator. In the case the message is an IETF
standardized PA attribute exchange, the standard PA Message Vendor id
(0) and the standard set of PA sub-types will be used with an all f's
PVI, which will cause the message to be routed by the PB server to all
the Posture Validators on the PB server that claim to be belonging to
the "standard sub-types" listed in PA-TNC. The contacted Validator's
will respond with the response which will be packaged by the PB Server
with the appropriate PVI so that further communication can continue with
specific Validators if required.  



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.

Ravi> good point - as you suggest we should add a timer field such that
the Posture Client can reconnect after the timer expires. I think this
will address the issue you highlight above. Another note - It may be
useful to also have a new command code to allow for a server initiated
re-assessment - this is for cases when an event occurs in the network
(for example, detected by some intrusion detection system) that causes
the NEA server to reevaluate the posture of the NEA client.



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.

Ravi> Agree also - We should add in the next rev.



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

Ravi> thanks for the good clarification to the section - we should add
it in the next rev.


Regards,
Ravi

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