Re: [Nea] Comments regarding draft-khosravi-nea-requirements-01.txt Part 1



Greetings,


      My knee-jerk reactions to Brian's email inserted inline_

"Brian Ford \(brford\)" <brford@cisco.com> wrote on 06/30/2006 03:45:44 PM:

>
> Comments regarding "Requirements for Network Endpoint Assessment (NEA)
> draft-khosravi-nea-requirements-01.txt" Part 1
>
> Comments submitted by Brian Ford (brford@cisco.com), Consulting
> Engineer, Cisco Systems
>
> [#1] In the abstract it says: "NEA provides owners of networks (e.g. an
> enterprise offering remote access) a mechanism to learn the operational
> state or posture of a system requesting network access and then apply
> this knowledge to the network admission decision.  Why call out "an
> enterprise offering remote access"?  Couldn't this capability be used by
> enterprise and service (and all) providers alike over wired and wireless
> networks?

      It could and should be used by all of the above. Calling out the
enterprise remote access as an example does not preclude other uses, so the
way I read it the enterprise is just that_ an example. Or did a miss some
new meaning for "e.g."?

>
> [#2] In the abstract it says: "This information is frequently useful for
> detecting systems that are lacking (or have out of date) security
> protective mechanisms (e.g. anti-virus, firewall.)".  The NEA protection
> model protects the network and authorized hosts on the network from
> threats introduced by new hosts joining the network. You don't mention
> that NEA adds a new authentication point (established when the agent
> determines whether to share posture data with the network validator).
> Could you add something about protecting the network and other network
> hosts from hosts for which services are not available?
>

      I don't agree that NEA adds a new authentication point. In my
vernacular, authentication is the function of determing the identity of
someone (or thing). NEA is about integrity, not identity. I consider NEA
more of an authorization function.

      Also, I don't understand how authentication relates to hosts for
which services are not available. While I believe that there should be a
way to handle such hosts, it might not be a function of the NEA spec itself
but rather of a best practice to manage clientless hosts in parallel with
NEA. I agree that the abstract should mention the clientless host problem
and either address the problem or explicitly state that it does not address
the problem.

> [#3] Please consider the following rewording of the Introduction:
>
> "Today, network providers can leverage existing standards-based
> technologies to restrict access to the network based upon the requesting
> system's user or host-based identity, source IP address or physical
> access point. These approaches do not currently attempt to take into
> account the configuration or state of a host attempting to access the
> network in order to improve an access decision.  In order to reduce the
> overall risk assumed in operating a network, operators need the ability
> to assess hosts configuration and operational state to ensure that they
> meet the operational requirements of the network before participating.
> Network Endpoint Assessment (NEA) has been offered to fulfill this need.
>
> Given such a capability components in the network could preemptively
> detect systems that are potentially dangerous to the network. This
> capability provides the network operator greater control over hosts that
> are admitted so that they might insure that the protections the network
> offers better match the potential threats that could be presented by any
> host.
>
> If a host is determined to be presenting a configuration that does not
> meet the network operators admission policy; for example if a host is
> lacking proper defensive mechanisms such as operational and up to date
> firewall or anti-virus software there should be a way to safely repair
> or remediate that host so that it can be subsequently trusted to join
> and operate on the network."
>

      That sounds spot on but is in need of a bit of wordsmithing.

>
> [#4] In the Introduction it says: "NEA typically involves the use of
> trusted agents running on the requesting machine ...".  Given that this
> document sets out requirements for NEA and that there are few
> implementations of the as yet undefined NEA; perhaps the use of the word
> "typically" is premature.
>

      Interesting point, which brings us back to the clientless host issue.

> [#5] In the Introduction when you point out that "Architectures, similar
> to NEA, have been defined in the industry (e.g. TNC, NAP, NAC) to
> assess"; how about listing those systems in alphabetical order (e.g.
> NAC, NAP, TNC).  Or perhaps listing solutions that have been implemented
> first.
>

      Or how about putting them in order from least proprietary to most
proprietary? We could just leave it alone then! I really have no preference
but had to say that! ;-b


> [#6] In the Introduction it says: "The decision might allow for no
> access, limited access (possibly to allow for remediation), or full
> access to the network.".  I'd suggest that these options could better be
> summarized as "variable access to the network ranging from none to full
> access; access to an alternative network that could be used to remediate
> the host or provide guest access; or access to the Internet".
>

      I agree we should change this.

> Thanks for your consideration.
>
> Liberty for All
>
> Brian
>
> Brian Ford
> Consulting Engineer
> Cisco Systems, Inc.
> http://www.cisco.com <http://www.cisco.com/>
>
> _______________________________________________
> Nea mailing list
> Nea@ietf.org
> https://www1.ietf.org/mailman/listinfo/nea


Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software