Network Endpoint Assessment (NEA): Overview and Requirements
draft-ietf-nea-requirements-07

This requirements effort is clearly excessive due to the length and
complexity of this document.  It's certainly time to start real work
and not waste time on requirements any longer.  I also suspect
anything that meets all the requirements will suffer
second system syndrome badly and fail to deploy.  Think simple.

A few cautions from my applications experience based on some of the
questionable requirements:

* It is likely that the ease of debugging the protocol will be much more
important in practice than the number of octets it consumes.  A binary
protocol is probably not a good idea here.  If you really have bandwidth
issues, a general purpose compression layer (e.g. the one available as
a TLS or SSH option) is usually better than custom binary complexity
that makes the protocol harder to debug.

* It's my experience that trying to flatten truly structured data into
attribute/value pairs (where all sorts of hierarchy semantics get some
sort of nasty encoding in the attribute names) is a mistake.  If you
really need to get into the bowels of firewall configuration (something
I doubt) then you'll want support for generic structure, and likely
XML is your best choice for representing extensible generic structure.

Netconf might be a good fit for this...

Comment based on input from OPS-DIR member Kurt Eril Lindqvist:

NEA was brought to the IETF partly by 'real' network managers who said they had a real problem to solve.  As this is fairly unusual these days, I have all respect for the fact that they wanted to solve a problem. I would also agree that NEA seems  to solve a 'inventory problem' in a good way.
 
The above said, I do have some scaling concerns. For example, I would assume that the posture client makes sure that not all clients on a large network would start initiating posture exchanges at the same time after for example a large power outage. The document in general talks very little about how the policies are to be managed and how the interaction with users is expected to be conducted.

Section 7., paragraph 0:
>  7. Requirements (Only Normative Section)

  This is an Informational document and hence cannot have any normative
  sections. I suggest to remove the text in parens from the heading and
  rephrase the first sentence of the following paragraph.


Section 7.3, paragraph 9:
>      PB-6 The PB protocol MUST support grouping of attribute messages
>           to optimize transport of messages and minimize round trips.

  If by "minimize round trips" you mean "minimize delay", grouping
  messages will do the exact opposite - it will end up increasing delay.


Section 7.4, paragraph 7:
>      PT-5 The PT protocol SHOULD be able to run between a NEA Client
>           and NEA Server over TCP or UDP (similar to LDAP).

  TCP gives you the transport mechanisms that PT-3 requires. UDP does
  not, and in order to use UDP, NEA will need to specify mechanisms for
  fragmentation, reliable delivery, duplication detection and reordering
  for itself. As I mentioned in my DISCUSS above, I strongly urge NEA to
  pick a single transport protocol, such as TLS-over-TCP, which seems to
  have all the mechanisms needed to support requirements PT-1 to PT-4.

  Comments are from Scott Brim's Gen-ART Review.

  Abstract

  - "evaluate the posture of a system"

    For clarity please use "endpoint" (as you do throughout the rest
    of the document) instead of "system".  A naive reader can't tell
    if "system" refers to the entire system dealt with in the
    reference model (just discussed, so in the reader's mind) or a
    client end system, a home network or what.  Maybe "system" is a
    relict.

  2. Terminology

  - "Attribute - Data element including any requisite meta-data
    describing an observed, expected or operational status of an
    endpoint feature (e.g. anti-virus software)."

    I understand the difference between observed and expected, but
    what's the difference between observed and operational?  If there
    is one, maybe you could use a few more words to make the
    difference clear.

  - "Endpoint - Any host computing device that can be connected ..."

    Delete "host".  This isn't the 1970s anymore, or even the 1980s.
    Most endpoints don't host anything.

    Make this a global change except where well-established protocols
    or concepts have "host" in their name.

  - "The owner may permit user override or augmentation of control
    policies or may not assert any policies limiting use of asset."

    "may not" is almost always dangerously ambiguous regardless of
    capitalization.  It could mean that the owner is not allowed to
    assert any policies.  How about: "or may not" -> "and need not".

  - "Posture Attributes - Attributes describing a quality or status
    (posture) of an feature of the endpoint."

    Above, in "posture", you said "configuration or status", which
    makes sense.  Here you have "quality or status of an feature".
    "Quality" is undefined here.  I would avoid it.  By the way change
    "an feature" -> "a feature" if you don't delete it.

  4. Problem Statement

  - "Endpoints that are not NEA-capable or choose not to share
    sufficient posture to evaluate compliance may be subject to
    different access policies."

    They are subject to the same *policies*, but the result of
    *applying* those policies may be different (e.g. limited access).
    Perhaps you can say "... subject to different application of
    access policies", or if you don't like that perhaps "... subject
    to different access policy rules".

  5. Reference Model

  - I would expand the PA and PB acronyms the first time they are used
    here.  They are expanded up at the beginning of Scope, but not
    here, where they discussed for a while before being expanded.

  - "The specific methods of referencing the configuration and
    establishing the communication channel are out of scope for the
    NEA reference model and should be covered in the specifications of
    candidate protocols for the Posture Transport (PT) protocol."

    I would delete "and should be ... ".  Just say it's out of scope,
    not which draft it should be covered in.  Give yourself the
    freedom to cover the issue in other drafts any way you like.

  5.1.1 NEA client

  - "Endpoints lacking NEA Client software (which is out of NEA scope)
    or choosing not to provide the attributes required by the NEA
    Server could be considered non-compliant and subject to different
    access policies."

    Same comment on Section 4.  To me, the access policies seem to be
    the same, but different rules within policies apply.  For clarity
    I would end the sentence at "could be considered non-compliant".
    That's all you need to say.  Stop there.

  6.1.1.1 example

  - "The NEA Server determines that the system is lacking a recent
    security patch designed to fix a serious vulnerability and the
    system is placed on a restricted access network.  ...  Later, the
    desktop requests again to join the network and this time is
    allowed on the enterprise network ..."

    Could you be clearer about "the enterprise network" etc.?  When
    you say placed on a restricted access network, are you talking
    about an L2 VPN?  Obviously the endpoint is "on the network",
    perhaps even "the enterprise network", or you wouldn't be able to
    do the assessment in the first place.  (This is a global, but not
    straightforward, change.)

  7.2 PA requirements

  - "PA-1 The PA protocol MUST support communication of an extensible
    set of NEA standards defined attributes.  These attributes will be
    uniquely identifiable from non-standard attributes."

    "uniquely identifiable from" -> "distinguishable from"

  - "PA-2 The PA protocol MUST support communication of an extensible
    set of vendor-specific attributes.  These attributes will be
    segmented into uniquely identifiable vendor specific name spaces."

    "uniquely identifiable" -> "uniquely identified".

    "vendor specific" -> "vendor-specific".

  7.3 PB requirements

  - "PB-2 The PB protocol MUST NOT interpret the contents of PA
    messages being carried, i.e., the data it is carrying must be
    opaque to it."

    Do you really care if PB happens to interpret PA, perhaps for some
    kind of monitoring?  Is there a confidentiality issue between PA
    and PB?  Or is the real requirement that there can't be a
    dependency -- the PB protocol MUST NOT depend on interpreting PA
    messages in order to meet the requirements of supporting PA.

  7.4 PT requirements

  - Same comment as for 7.3 on "must not interpret".