Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Oct 2006 17:09:58 +0200

> I run a very closed network, ports are closed and not opened unless there is
> a validated request, external drives are disabled etc etc.  A contractor
> comes in with a notebook and needs to work on some files located on our
> internal secure network.  A trusted staff member rings in with the request
> to open a specified port.  The port is opened and the contractor hooks up
> the laptop to it.  NEA does it's thing and if the laptop doesn't match the
> requirements of the internal network policy it is directed to a sandbox
> network for remediation.  If the laptop does meet the policy then it allowed
> onto the internal network.  

What if your contractor has carefully configured the laptop to
give all the right answers? What if it has already been infected with
a virus that causes it to give all the right answers?

The first case is certainly current practice, and the second one could
arrive any day.

     Brian

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

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Thu, 12 Oct 2006 06:53:52 +1000

Brian E Carpenter wrote:
>>> I run a very closed network, ports are closed and not opened unless
>>> there is a validated request, external drives are disabled etc etc.
>>> A contractor comes in with a notebook and needs to work on some
>>> files located on our internal secure network.  A trusted staff
>>> member rings in with the request to open a specified port.  The
>>> port is opened and the contractor hooks up the laptop to it.  NEA
>>> does it's thing and if the laptop doesn't match the requirements of
>>> the internal network policy it is directed to a sandbox network for
>>> remediation.  If the laptop does meet the policy then it allowed
>> What if your contractor has carefully configured the laptop
>> to give all the right answers? What if it has already been
>> infected with a virus that causes it to give all the right answers?
>> 
>> The first case is certainly current practice, and the second
>> one could arrive any day.

Hello Brian

I would be monitoring for unusual behaviour on the network and would be
warned if the laptop started to behave in ways not expected.  NEA would only
save time in getting the system onto the network as instead of physically
inspecting it I'd be relying on automated means to judge compliance.  It
would be an acceptable risk.  The risk of someone wishing to hack in or
being infected with a virus as you describe is low.  I'd mainly be using NEA
to assist in those situations where the trust isn't total but there isn't
harmful intent.

If you know of a system that provides total protection, is easy for users to
perform their duties and doesn't have me or IT staff doing physical checks
I'd be more than willing to look at it.

Let's face it, there will always be a risk of someone getting around any
informational or protection mechanism put into play, we all have to judge
that risk and set up networks accordingly.  If we really want to be secure
we wouldn't allow any ad hoc connections at all.

Darryl (Dassa) Lynch

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 11 Oct 2006 23:59:41 -0400

> a virus that causes it to give all the right answers?

  Yes, that's a problem with NEA.  No, it's not a problem for many (if
not most) people using NEA.

  The people I talk with plan on using NEA to catch the 99% case of a
misconfigured/unknown system that is used by a well-meaning but
perhaps less clueful employee or contractor.  The purpose of NEA is to
enhance network security by allowing fewer insecure end hosts in the
network.

  No one can prevent a determined attacker from getting in.  But by
providing fewer hosts for him to attack, the attacks become less
feasibly, and more visible.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 11 Oct 2006 23:59:41 -0400

Alan DeKok.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Oct 2006 14:40:02 +0200

> enhance network security by allowing fewer insecure end hosts in the 

I think the requirements document and/or charter would do well to stress 
this. Perhaps even exclude the 1% case explicitly.

Arnt

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Oct 2006 06:23:45 -0700

A typical NEA case (taken out of what Cisco's NAC is supposed to be good 
for):

- Worker goes on holiday, takes laptop
- New attack is discovered that exploits a newly discovered Windows 
vulnerability
- Patch is created, distributed and installed
- NEA posture requirement is increased to "must have patch"
- Worker comes back, plugs in laptop

Without NEA-like functionality:
- Worker is admitted
- Worker gets attacked & compromised
- IDS & other alarms go off
- Remediation efforts do what they usually do

With NEA:
- Worker gets sandboxed
- Worker gets upgraded
- Worker gets admitted
- No compromise, so no remediation

No ill intent on the part of any participant (except the attacker). Just 
a TCO issue.

The fact that some fruit is low-hanging doesn't mean it's not worth picking.

                   Harald

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Oct 2006 09:21:38 -0700

> The fact that some fruit is low-hanging doesn't mean it's not worth 

I don't agree that this is low-hanging fruit.
The server component of this system seems like a wonderful
new target for DDoS and masquerade attacks.

>                   Harald

Andy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Oct 2006 08:10:32 +0200

> new target for DDoS and masquerade attacks.
Well, first of all I don't see why this is any different than a radius
server.  In fact it could be that the access box forwards information in
a very similar way.  But let's say that it doesn't work that way just
for yucks.  Another approach is that the clients themselves must have a
server on them and the queries go the other way.  In this case the
server need only check either a source address or a transaction ID. 
Furthermore, there is no reason for clients outside of that AS to have
access to that server, so it's a good candidate for an ACL.  Of course
this creates a risk of attack on the clients themselves, which brings me
to one of my greater concerns:

In many of the mechanisms that communicate between client and network we
are not finding good ways to prove the legitimacy of the service to the
client.  This is an area that perhaps it would be good to get the IRTF
to work on.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 06:33:11 -0700

> client.  This is an area that perhaps it would be good to get the IRTF

My comment was on Harald's characterization of this work effort
as 'low hanging fruit'.  IMO, that term is reserved for huge gains
for very little effort.  I don't think that is the case here.

Andy

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 16 Oct 2006 17:37:34 -0700

Harald,
This seems to be missing the point. I think there is a general sense
that NEA could be helpful for some level of protection to complying
endpoints in an enterprise scenario, which is exactly what you have
described below. The disagreement seems to be on the topics of what NEA
does for the network and whether it makes any sense in the provider
model where the network and end device owners are different. 

On the network protection issue, I still have not seen anything that NEA
provides that is not provided (in a better manner) by protection
mechanisms that the network must use to protect itself against any
unknown vulnerabilities and compromised endpoints. Everything that has
been said still seems to be a subset of that larger threat which must be
protected against anyway. Having said that, the use of NEA for the
provider model doesn't make sense, since providers are interested in
protecting their networks more than protecting the devices they don't
own. Not to mention that they cannot really hope to get compliance from
devices they don't own. 

Vidya 

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 6:24 AM
> To: Alan DeKok
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
> 
> - New attack is discovered that exploits a newly discovered 
> Windows vulnerability
> No ill intent on the part of any participant (except the 
> attacker). Just a TCO issue.
> 
> >> What if your contractor has carefully configured the 
> laptop to give 
> >> all the right answers? What if it has already been infected with a 
> >> virus that causes it to give all the right answers?
> >>     
> >

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2006 08:06:20 +0200

> model where the network and end device owners are different. 
I'm not sure who is missing what point at this time....
note that the term "network" does NOT mean "ISP network". People who use 
it as if it means that contribute to confusion.

Also, the term "network" has been used both in the meaning of "layer 3 
network" and in the meaning of "the set of interconnected devices that 
make up the computing environment of an enterprise".
> mech any meaningful PA-level
interoperability. I am not sure what minimum set of PA attributes will
be standardized, but, whatever that set is, I doubt will be sufficient
to provide any acceptable level of security, even for the endpoints.
Even assuming ongoing standardization of vendor specific attributes, it
is not totally realistic to assume that all applications will support
the appropriate attributes. The rate of standardization is also very
likely to be much slower than the rate of the growth in the number of
attributes needed for any continued meaningful protection.=20

Regards,
Vidya

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2006 08:06:20 +0200

Regards,
Vidya

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2006 08:06:20 +0200

> own. Not to mention that they cannot really hope to get compliance from
Noting the scenarios above, I claim that NEA-like functionality has 
proved useful already in protecting "the computing environment of an 
enterprise". I have not seen compelling evidence that it has any use in 
"the layer 3 infrastructure used to carry customer traffic at an ISP".

But I think that's beside the point - the use cases for which we know 
that NEA may be useful are already compelling enough that we should stop 
debating whether or not to charter the group and get on with the work.

My opinion.

                Harald

anisms that the network must use to protect itself against any
> own. Not to mention that they cannot really hope to get compliance from
Noting the scenarios above, I claim that NEA-like functionality has 
proved useful already in protecting "the computing environment of an 
enterprise". I have not seen compelling evidence that it has any use in 
"the layer 3 infrastructure used to carry customer traffic at an ISP".

But I think that's beside the point - the use cases for which we know 
that NEA may be useful are already compelling enough that we should stop 
debating whether or not to charter the group and get on with the work.

My opinion.

                Harald

anisms that the network must use to protect itself against any
> own. Not to mention that they cannot really hope to get compliance from
Noting the scenarios above, I claim that NEA-like functionality has 
proved useful already in protecting "the computing environment of an 
enterprise". I have not seen compelling evidence that it has any use in 
"the layer 3 infrastructure used to carry customer traffic at an ISP".

But I think that's beside the point - the use cases for which we know 
that NEA may be useful are already compelling enough that we should stop 
debating whether or not to charter the group and get on with the work.

My opinion.

                Harald

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 17 Oct 2006 00:12:06 -0700

At 11:06 PM 10/16/2006, Harald Alvestrand wrote:
>><snip>
>enterprise". I have not seen compelling evidence that it has any use 
>in "the layer 3 infrastructure used to carry customer traffic at an ISP".
>
>But I think that's beside the point - the use cases for which we 
>know that NEA may be useful are already compelling enough that we 
>should stop debating whether or not to charter the group and get on 
>with the work.

It seems that there are a number of people believing that NEA might 
be useful in Enterprise networks where the network and the endpoints 
attaching to the network are owned and "controlled" by the same 
entity.  I know your words are "proved" useful; but perhaps we might 
agree that it's an arms race, so to speak.  Note that the notion of 
"proved" useful is unlike the type of guarantees we are used to in 
the Security area.

The charter currently says in part "There is an open issue with 
respect to NEA applicability in deployment scenarios where the 
endpoint is owned by a party that is different from the organization 
providing network access."

That is ambiguous.  I suggested adding the following applicability 
statement before:

"NEA is applicable to networks where endpoints accessing the network 
are owned and tightly controlled by the organization that owns and 
operates the network.  In all other cases, NEA and associated 
procedures and protocols are ineffective."

That also seems ambiguous as per the recent discussions, so I propose 
the following revision, based on your words Harald:

"NEA is applicable to computing environments of enterprises where 
endpoints accessing the enterprise's network are owned and/or 
expected to conform to the policies set forth by the organization 
that owns and operates the network.  In all other cases, NEA and 
associated procedures and protocols are ineffective."

Let us make that change so it is clear to everyone as to what NEA 
might and might not do.

Lakshminath

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2006 09:29:26 +0200

Lakshminath Dondeti wrote:
>> that NEA may be useful are already compelling enough that we should 
>> stop debating whether or not to charter the group and get on with the 
>> work.
>
> It seems that there are a number of people believing that NEA might be 
> useful in Enterprise networks where the network and the endpoints 
> "proved" useful is unlike the type of guarantees we are used to in the 
> Security area.
>
> endpoints accessing the enterprise's network are owned and/or expected 
> to conform to the policies set forth by the organization that owns and 
I don't think we have any proof that this statement is true. I can think 
of scenarios where NEA would be useful, but they depend on various 
circumstances that either would be very specialized or require a great 
deal of faith in order to believe they would happen.

I suggest:

"All other cases are outside the scope of the NEA charter, since we do 
not know that NEA would be useful in such cases."

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 17 Oct 2006 00:39:48 -0700

At 12:29 AM 10/17/2006, Harald Alvestrand wrote:
>I don't think we have any proof that this statement is true. I can 
>think of scenarios where NEA would be useful, but they depend on 
>various circumstances that either would be very specialized or 
>require a great deal of faith in order to believe they would happen.
>
>I suggest:
>
>"All other cases are outside the scope of the NEA charter, since we 
>do not know that NEA would be useful in such cases."

Ok.

For the benefit of the editor:

Let us replace:

"There is an open issue with respect to NEA applicability in 
deployment scenarios where the endpoint is owned by a party that is 
different from the organization providing network access."

with

"NEA is applicable to computing environments of enterprises where 
endpoints accessing the enterprise's network are owned and/or 
expected to conform to the policies set forth by the organization 
that owns and operates the network.  All other cases are outside the 
scope of the NEA charter, since we do not know that NEA would be 
useful in such cases."

Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Oct 2006 14:01:03 -0700

Hi Lakshminath, Harald, 

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 12:40 AM
> To: Harald Alvestrand
> Cc: Narayanan, Vidya; [email-masked]; [email-masked]; Alan DeKok
> >various circumstances that either would be very specialized 
> or require 
> >a great deal of faith in order to believe they would happen.
> >
> >I suggest:
> >
> deployment scenarios where the endpoint is owned by a party 
> that is different from the organization providing network access."
> 
> with
> 
> "NEA is applicable to computing environments of enterprises 
> where endpoints accessing the enterprise's network are owned 
> and/or expected to conform to the policies set forth by the 
> organization that owns and operates the network.  All other 
> cases are outside the scope of the NEA charter, since we do 

This text sounds okay to me. 

Vidya

---

From: Ned Freed <[email-masked]>
Date: Wed, 18 Oct 2006 14:25:35 -0700 (PDT)

> My opinion.

I concur. I will also add that my concerns about this work being used outside
it's domain of applicability (which as a practical matter we have little
control over) pale in comparison to concerns about there being mulitple
proprietary schemes for this sort of thing. The last thing we need to be doing
is encouraging monocultures through the work we do (or don't) do.

I also think this discussion is well over the line of charter debate and into
the realm of protocol design. Let's finalize the charter (I thought the latest
proposed text regarding scope looked fine) and do the protocol work in the WG.

				Ned