Subject: [Nea] Verifying NEA WG Consensus from Dublin

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 23 Sep 2008 10:44:35 -0400

I'd like to verify WG consensus on a few items that
were discussed at the NEA WG meeting at IETF 72.
All of these seemed to have consensus among those who
attended the meeting but I would like to verify that
consensus on the NEA email list since only consensus
on the email list is true WG consensus in the IETF.
Therefore, please send email to the list to indicate
if you agree with these items and, if not, which ones
you disagree with and why.

Please respond within two weeks (by October 7)
so that the PA-TNC and PB-TNC editors can complete
the next revisions of these drafts promptly.

I will send out another email in a minute on a
topic that did not seem to have consensus at the
NEA meeting in Dublin: IANA Considerations.

Thanks,

Steve

PB-TNC Changes
--------------
Ravi Sahita proposed moving the PB-Batch-Type to the PB-TNC header.
This is a 16 bit integer with enumerated values that indicate
the type of the batch. It's currently carried in a PB-TNC message
of type PB-Batch-Type but we require that there be one and only
one such message in each batch so it seems that it would just
be simpler and more efficient to move this field into the PB-TNC
header. We already have 24 reserved bits in that header so
there's no problem with making this change.

When a full-duplex PT is being used, we'd like to allow either the
NEA Client or NEA Server to request a retry at any time. Right now,
PB-TNC is strictly half-duplex even if the PT is not and that tightly
restricts when the NEA Client and NEA Server can request retries
(only when it's their turn to send). That causes problems if one side
detects a problem such as a change in policy or in endpoint
configuration. They might have to wait a long time to be able to
signal this problem and request a retry. In fact, they might have to
wait indefinitely. This change is not a big one but it does modify
the state machine to indicate that whenever SRETRY is allowed,
CRETRY is also allowed and vice versa.

A PB-TNC RESULT batch currently includes an Access-Recommendation
that contains one of the values Access Allowed, Quarantined, or Access
Denied. There's currently no way in PB-TNC to indicate whether the
NEA Client was found to be compliant with policy. So we suggest adding
posture assessment that could have values like Compliant, Non-Compliant,
Non-Compliant Major Issue, Error, and Don't Know.

PA-TNC Changes
--------------

First, we propose changing how attribute correlation is handled.
Currently, a Correlation ID is used to handle the case where a
single Posture Collector is able to gather information on
several products. This is somewhat unusual but it causes problems
since that Posture Collector might send a single PA-TNC message
with multiple Product Information, Numeric Version, and Operational
Status attributes, for example. Which Product Information attribute
goes with which Numeric Version Attribute? Today, we solve this
problem by tagging the attributes with an optional Correlation ID.
The proposed new solution to this problem is to have a Posture
Collector that wants to report on several products use a different
Posture Collector ID for each product that it reports on. This removes
the need to have a special protocol feature to handle this case.
Effectively, it pushes the tagging up the stack into PB where we
already have a field that can be used to solve this problem.
The main advantage is that it simplifies the protocol. The main
disadvantage is that it complicates the Posture Broker Client
and Posture Collector implementation if they want to handle this
case since they need to handle "virtual" Posture Collector IDs.

The second suggested change in PA-TNC is the addition of an Assessment
Result attribute that would allow a Posture Validator to inform a
Posture Collector about the compliance decision for a component, just
like the similar proposal for PB-TNC above but specific to a component.

The third suggested change in PA-TNC is the addition of a Remediation
attribute that would allow a Posture Validator to send remediation
instructions to a Posture Collector. This is a valuable feature since
the Posture Collector is the best place to do automated remediation.
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea