Re: [Nea] Comments on draft-sangster-nea-pa-tnc-00..txt

["Paul Sangster" <Paul_Sangster at symantec.com>]

Gary,

Thanks for the quick feedback on the spec.  I've provided some in-lined
comments and answers to some of your questions. 

> -----Original Message-----
> From: nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On 
> Behalf Of Gary Tomlinson
> Sent: Friday, February 29, 2008 11:49 AM
> To: nea at ietf.org
> Subject: [Nea] Comments on draft-sangster-nea-pa-tnc-00..txt
> 
> The following comments are regarding the individual 
> submission draft-sangster-nea-pa-tnc-00.txt of a PA protocol 
> for consideration by the NEA WG as a base to develop the PA 
> protocol from.
> 
> Again, I am impressed (like I was with the PB submission from 
> TNC) with the level of completeness in this proposal (no 
> doubt due to the maturity of the TNC work) and think it 
> warrants strong consideration by the WG as a starting point.

Thanks

> 
> As usual, I do have a number of specific comments.
> 
> First, I have a general comment regarding the IETF Vendor Id 
> value 0 as it is applied in this document.  I found having 
> repeated per IETF name space PA subtype (all those defined in 
> this specification) qualification to the IETF Vendor Id to be 
> redundant and make it harder to get to the chase of each PA 
> subtype structure.  Given section 2.4 clearly states all PA 
> subtypes defined in this document are applicable to only the 
> IETF vendor ID, I think it would be good to simplify the 
> prose per PA subtype and eliminate the interpretation of name 
> space qualification to Vendor Id 0. This comment does not 
> apply to Vendor ID usage within attribute types as there is a 
> need to distinguish at this level in cases such as page 36, 
> section 3.2.8.

So you're suggesting not repeatedly mentioning in the prose that vendor
id of 0 is IETF so save spec bloat?  We were trying to be complete in
the normative part of the spec (protocol definition) but if others agree
this is causing issues we could emphasize it more earlier in the spec
and remove those repeated comments.  Thoughts?

> 
> Page 10, section 2.4.  I can't find any definitions for the 
> PA subtypes in this document nor in any of the references.  
> Given these are being defined in the IETF name space, I think 
> it is necessary to eliminate ambiguity as I'd guess not 
> everyone in the WG has a consistent definition of them let 
> alone people outside this work group.  Ideally from my point 
> of view, a set informative references can be found that address this.

Do you have a reference in mind?  Clearly column 3 gives a very terse
definition of each one so it sounds like you would like something more
developed.  Suggestions are welcome particularly if they are used in
other standards (not sure wikipedia entries count :)).

> 
> Page 12, section 2.5 Message Identifier.  Why is the PA 
> protocol state machine not required to check for duplicate 
> identifiers if this is a protocol violation?  Not requiring 
> this seems like a recipe for trouble.

This was really just leaving it open for implementations to make this
decision.  I'm fine with removing that sentence if other agree with your
comment.  However the identifier is really for use by the sender so if
it mistakenly repeats an identifier its causing problems just for itself
(not the recipient).  For example if a sender incorrectly sends 2
messages during an assessment that have the same message identifier and
one causes an error, then when the sender gets the error message it
won't be able to properly use the identifier to know which message
caused the problem.  The recipients state machine isn't affected by this
number so thus doesn't need to check it.  However a robust
implementation may choose to check it to avoid potential assessment
issue by a poorly implemented peer.

> 
> Page 30, section 3.2.6.  Why is the Port Filter attribute 
> support restriction applied to VPN subtypes?  I can see it 
> being applied to layer 4 firewall collectors, but find VPN a 
> little muddy.  I realize many VPN clients do provide layer 4 
> port filtering, however I see that as a firewall service that 
> is being provided in addition to VPN, and as such would think 
> these components should register themselves as both a VPN and 
> a Firewall subtype.

The short answer is that the spec tries to identify what kinds of
attributes (e.g. Port Filter) are applicable to each type of component
type (e.g. VPN).  Many attributes don't make sense with certain types of
components so we call out the ones where we do believe they are
compatible.  This doesn't require that collectors for VPN components
MUST support this attribute but if the VPN supports a firewall (as many
do - and all IPsec VPNs MUST) then this attribute is applicable to the
VPN and therefore should be supported.

> 
> Page 32, section 3.2.6.  Why is there a restriction on mixed 
> blocked and non-blocked protocol/port pairs in a single port 
> filter list attribute?
> Each protocol/port element has its own flags field and thus 
> is capable of being unambiguously qualified as blocked or 
> non-blocked in the protocol.

See the following sentence which says: 

"To be more precise, a Posture Collector MUST NOT include two
Protocol/Port Number pairs in a single Port Filter attribute where the
protocol number is the same but the B flag is different."

This is requesting that there not be a entry saying "TCP port 80 is
allowed" followed by an entry saying "TCP port 80 is blocked" thus
creating an ambiguous policy (depends on how policy matching happens
during enforcement).

> 
> Pages 40-43, section 3.2.8.1. Just a nit here, but there is 
> inconsistency in the labeling of copied fields in the 
> diagrams.  Some are labeled "Copy of ..." and other and 
> simply "...".  All of them that are copies should be labeled 
> "Copy of...".

We can probably remove that rather then having "Copy of" all over the
place.  We were trying to emphasize that this reserved field is
different from the others (which need to be set of 0 and ignored).  I'll
remove "Copy of" if its too inconsistent.

> 
> Page 46, section 4.8.  What is the definition of typical 
> here?  Is it an observation from systems deployed in the 
> field today; and if so are they using a protocol similar to 
> PA-TNC?  Also, given PA-TNC allows vendor defined attributes 
> with who knows how much size, like say X.509 chains, I 
> suggest any mention of typical be qualified by use of PA-TNC 
> defined IETF name space attributes.

We'll drop the word "typical".  The idea was trying to describe an
expected result based on today's deployment experience.

> 
> Page 60, reference 8.  Why is this informative and not 
> speculatively normative?

We wanted to limit the normative reference to specification that are
contributing normative requirements to the spec.  Since this is a
standards track spec we want to limit normative references to other
non-standards track documents (such as 6 and 7).

> 
> Gary
> 
> _______________________________________________
> 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