Subject: [Nea] REQ -03 comments

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Jul 2007 11:50:05 -0400

Overall, much more comprehensible than earlier versions.

  General comments:

* Section 1 is still complex.  Sentences are long, and seem to be
marketing-speak:

    Today, most network providers can leverage existing standards-
    based technologies to restrict access to their network based
    upon criteria such as the requesting system's user or host-based
    identity, source IP address or physical access point.

  Simplicity would be good.

* The goal seems to be:
  1) inventory of software on the device
  2) informing the device what software *should* be running
  3) informing the device where to obtain the software
  4) informing the switch how to treat / block the devices traffic

* I'm not sure what some sentences mean:

   Posture Attributes - Attributes describing a quality or
      characteristic of a component.

  The following text clarifies it a little, but it still sounds complex.
  Versus:

  Posture Attributes - Attributes describing the status
     of a component.  This may include information such as manufacturer,
     product name, version number, last update time, install time,
     last modification time, etc.

* Section 5 seems to have "posture" as every other word.  Most instances
can probably be deleted.  Section 6.1 appears to be doing this already,
btw.  e.g.

    The NEA Client is resident on an endpoint device and comprises
    of the following components for assessing posture:
      o Collector(s)
      o Broker Client
      o Transport Client
...
    The NEA Server will typically comprise of the following logical
    components for assessing posture:
      o Validator(s)
      o Broker Server
      o Transport Server

* Terminology is still inconsistent and confusing:

    PA is a protocol that carries attribute messages between a
    Posture Collector and its associated Posture Validator.

  What's an "attribute message"?  The terminology section talks about
Messages and Request/Posture/* Attributes.

* Does the NEA server cache anything?

    The enterprise administrators make available the patches and
    change the network policy to require it to be installed by 5PM.
    This policy change causes the NEA Server to request a re-
    assessment to determine what endpoints are impacted and lacking
    the patches.  The marketing employee's laptop is re-assessed and
    determined to need the patches.

  If the NEA server caches the results of posture assessment, it *knows*
that the device is not compliant.  To first order, the server doesn't
have to cache anything other than "compliant at time X".  When the
policy changes at time "X + t", the device is trivially determined to be
noncompliant.  The NEA server may not know *what* is noncompliant, but a
full reassessment can address that.

  The NEA server can also cache the results of the last posture
assessment, and tell the device "download patch X from here..."  i.e. an
unsolicited posture requirement update, or remediation instruction.

  I will have more comments on Section 6 and following in a later message.

  Alan DeKok.

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Royer, David \(Best Buy Canada\)" <[email-masked]>
Date: Mon, 23 Jul 2007 10:46:32 -0700

I'm quite new to this distribution list, but I have extensive experience
with NEA solutions, eventough the technology is quite young at this
point.  To give you a quick background, I have evaluated multiple
solutions with the goal of implementing to a 10 000+ employee
environment, and also participated in the development of a product.

I went through the specification and I really like it.  I believe too
much simplicity would not make sense on this case, as the NEA market is
not a simple one, and there is no simple ways to develop and install a
NEA solution.  I feel more like this RFC could be separated into
multiple smaller ones to make things easier.

Although, as Alan mentioned, I also think more definitions / precision
should be added to the specification.  I'm more interested into the
Attribute Message and the protocol itself:  

- Should the need of encryption be specified?  
- Same with authentication: should client <-> server authentication need
should be described in the RFC as well?

>From a security perspective, protecting the Posture Messages is usually
a best practice, as it might contain enough information for a hacker to
take advantage of it.  As for authentication, some products might want
to work in a close environment, where the clients are easily
identifiable and pre-configured.  Some might use PKCS certs to
authentication, some other might use private/public key pairs.  But
anyhow, I was wondering if such definitions should be included in the
draft.

-David

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 8:50 AM
To: [email-masked]
Subject: [Nea] REQ -03 comments

  General comments:

* The goal seems to be:

  I will have more comments on Section 6 and following in a later
message.

  Alan DeKok.

The information in this e-mail message including any attachments is intended only for the named recipients above and may contain confidential or privileged information. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender by replying to the message and deleting all copies of it from your computer.

Ce courriel de même que toute pièce jointe s'adresse seulement au(x) destinataire(s) désigné(s) et peut contenir des renseignements confidentiels ou privilégiés. Si vous avez reçu ce message par erreur ou que vous n'êtes pas un destinataire désigné, veuillez avertir immédiatement l'expéditeur en répondant au message et effacez-en toutes les copies dans votre ordinateur.
_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea