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

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 8 Oct 2006 10:05:03 -0700

> -----Original Message-----
> From: Susmit Panjwani [mailto:[email-masked]] 
> Sent: Saturday, October 07, 2006 5:04 PM
> To: Harald Alvestrand
> Cc: Narayanan, Vidya; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
> 
> Third, I > > simply can't see what the organization's 
> interests would be in
> > > protecting a device that doesn't even belong to it.
> 
> An organization might not be interested in protee is bound to be
software/hardware that does not quite support NEA or specific posture
attributes. In a university environment, while some basic posture
reporting is feasible, there is bound to be a lot of software/hardware
that does not support any NEA parameters. The protection that even the
endhost may be getting from NEA is quite limited. 

> In any event, the bottomline is NEA as a solution to "network 
> protection" is a leaky bucket at best.
> 

The charter must be clarified to dispel this myth about NEA protecting
the network from anything.  

Vidya

> NEA at best *may* raise the bar in attacking a "closed" 
> network where endpoints are owned and tightly controlled by 
> the organization that owns the network.
> 
> Lakshminath
> 
> 
> >                    Harald
> >
> >
> >_______________________________________________
> >Ietf mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 8 Oct 2006 10:05:03 -0700

> An organization might not be interested in protecting a 
> device that does not belong to it but would definitely be 
> interested in preventing the attacks originating from such 
> device (if compromised) when it joins the organization 
> network.  

It appears that the NEA charter is completely misleading to some people
from what is stated in this email. As the NEA charter alludes to, NEA
does nothing to protect against compromised devices. Also, as has been
agreed, NEA is not a protection mechanism for the network - it is meant
to be a protection mechanism for compliant, truthful and as yet
uncompromised end hosts against known vulnerabilities. 

Any network, in its own best interests, must assume that it has lying
and compromised endpoints connecting to it and that there are unknown
vulnerabilities on any NEA-compliant devices connecting to it. Any kind
of protection that addresses these general threats that the network may
be exposed to at any time will simply obviate the need for NEA from the
network perspective. 

A network operator that thinks the network is getting any protection by
employing NEA is clearly ignoring the obvious real threats that the
network is exposed to at any time. 

This is what I meant when I said that the charter is unclear and it must
explicitly state that NEA is not meant as a protection mechanism of any
sort for the network. 

Vidya

> To cite a study that we performed at
> UMD: we did a cost-benefit analysis based on the captured 
> attacks from within the organization, and it turns out that 
> the organization would benefit significantly if they  
> implement any trusted network access technology.
> 
> I do realize that there would be issues in terms of user 
> privacy and interoperability(which this charter is trying to 
> tackle) but just wanted to mention that there would be 
> significant benefits if they can implement it. This is 
> especially true for university environment.  As a matter of 
> fact I am aware of some universities/departments that were 
> planning to implement a home grown solution for this.
> 
> Susmit
> 
> --
> Susmit Panjwani
> 
> PhD Candidate,
> Center for Risk and Reliability,
> University of Maryland
> Cell: 240-460-9782
> 
> 
> On 10/7/06, Harald Alvestrand <[email-masked]> wrote:
> > >
> > > The reason we left it open is to allow the working group to spend 
> > > more
> > > > time exploring the range of use cases in this area to better 
> > > > determine requirements and applicability. For example, 
> it may be 
> > > > useful to classify endpoints as network-managed versus 
> > > > user-managed versus 3rd-party managed. A user-managed 
> endpoint may 
> > > > want the choice to opt in or opt out, say.
> > > >
> > >
> > >
> > > Not only do I not see anything in the charter or milestones that 
> > > indicates that the WG is going to spend time exploring this, I 
> > > strongly believe this WG should not be spending any time 
> looking at 
> > > this. The trust models for the cases where the devices 
> are not owned 
> > > by the organization performing NEA are hugely different 
> and can take 
> > > up its own WG to actually find something that applies 
> there, if at 
> > > all. For one, this could be considered a violation of 
> privacy by the 
> > > user of the device. Secondly, the end user's perspective 
> of attacks 
> > > may be entirely different from the organization's perspective in 
> > > this case. Third, I simply can't see what the organization's 
> > > interests would be in protecting a device that doesn't 
> even belong 
> > > to it. Last but not the least, this requires the endpoint to be 
> > > running an NEA client (that is interoperable with the NEA 
> server of 
> > > the organization) - which in itself is often an 
> unrealistic requirement.
> > Many universities require their students to buy their own 
> laptops, but 
> > prohibit certain types of activity from those laptops (like 
> spamming, 
> > DDOS-attacks and the like). They would love to have the 
> abilicting a 
> device that does not belong to it but would definitely be 
> interested in preventing the attacks originating from such 
> device (if compromised) when it joins the organization 
> network.  

It appears that the NEA charter is completely misleading to some people
from what is stated in this email. As the NEA charter alludes to, NEA
does nothing to protect against compromised devices. Also, as has been
agreed, NEA is not a protection mechanism for the network - it is meant
to be a protection mechanism for compliant, truthful and as yet
uncompromised end hosts against known vulnerabilities. 

Any network, in its own best interests, must assume that it has lying
and compromised endpoints connecting to it and that there are unknown
vulnerabilities on any NEA-compliant devices connecting to it. Any kind
of protection that addresses these general threats that the network may
be exposed to at any time will simply obviate the need for NEA from the
network perspective. 

A network operator that thinks the network is getting any protection by
employing NEA is clearly ignoring the obvious real threats that the
network is exposed to at any time. 

This is what I meant when I said that the charter is unclear and it must
explicitly state that NEA is not meant as a protection mechanism of any
sort for the network. 

Vidya

> To cite a study that we performed at
> UMD: we did a cost-benefit analysis based on the captured 
> attacks from within the organization, and it turns out that 
> the organization would benefit significantly if they  
> implement any trusted network access technology.
> 
> I do realize that there would be issues in terms of user 
> privacy and interoperability(which this charter is trying to 
> tackle) but just wanted to mention that there would be 
> significant benefits if they can implement it. This is 
> especially true for university environment.  As a matter of 
> fact I am aware of some universities/departments that were 
> planning to implement a home grown solution for this.
> 
> Susmit
> 
> --
> Susmit Panjwani
> 
> PhD Candidate,
> Center for Risk and Reliability,
> University of Maryland
> Cell: 240-460-9782
> 
> 
> On 10/7/06, Harald Alvestrand <[email-masked]> wrote:
> > >
> > > The reason we left it open is to allow the working group to spend 
> > > more
> > > > time exploring the range of use cases in this area to better 
> > > > determine requirements and applicability. For example, 
> it may be 
> > > > useful to classify endpoints as network-managed versus 
> > > > user-managed versus 3rd-party managed. A user-managed 
> endpoint may 
> > > > want the choice to opt in or opt out, say.
> > > >
> > >
> > >
> > > Not only do I not see anything in the charter or milestones that 
> > > indicates that the WG is going to spend time exploring this, I 
> > > strongly believe this WG should not be spending any time 
> looking at 
> > > this. The trust models for the cases where the devices 
> are not owned 
> > > by the organization performing NEA are hugely different 
> and can take 
> > > up its own WG to actually find something that applies 
> there, if at 
> > > all. For one, this could be considered a violation of 
> privacy by the 
> > > user of the device. Secondly, the end user's perspective 
> of attacks 
> > > may be entirely different from the organization's perspective in 
> > > this case. Third, I simply can't see what the organization's 
> > > interests would be in protecting a device that doesn't 
> even belong 
> > > to it. Last but not the least, this requires the endpoint to be 
> > > running an NEA client (that is interoperable with the NEA 
> server of 
> > > the organization) - which in itself is often an 
> unrealistic requirement.
> > Many universities require their students to buy their own 
> laptops, but 
> > prohibit certain types of activity from those laptops (like 
> spamming, 
> > DDOS-attacks and the like). They would love to have the 
> ability to run 
> > some kind of NEA procedure to ensure that laptops are reasonably 
> > virus-free and free from known vulnerabilities, and are important 
> > enough in their students' lives that they can probably enforce it 
> > without a complaint about "violation of privacy".
> >
> > Just pointing out that there's one use case with user-managed 
> > endpoints where NEA is not obviously a bad idea.
> >
> >                     Harald
> >
> >
> > Nea mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nea
> >
> 

ty to run 
> > some kind of NEA procedure to ensure that laptops are reasonably 
> > virus-free and free from known vulnerabilities, and are important 
> > enough in their students' lives that they can probably enforce it 
> > without a complaint about "violation of privacy".
> >
> > Just pointing out that there's one use case with user-managed 
> > endpoints where NEA is not obviously a bad idea.
> >
> >                     Harald
> >
> >
> > Nea mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nea
> >
>

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Mon, 9 Oct 2006 07:20:27 +1000

Hi Vidya

Narayanan, Vidya wrote:
>>>>> Third, I simply can't see what the organization's interests would be
in
>>>> An organization might not be interested in protecting a device that
>>>> does not belong to it but would definitely be interested in
>>>> preventing the attacks originating from such device (if
>>>> compromised) when it joins the organization network.
>> 
>> It appears that the NEA charter is completely misleading to
>> some people from what is stated in this email. As the NEA
>> charter alludes to, NEA does nothing to protect against
>> compromised devices. Also, as has been agreed, NEA is not a
>> protection mechanism for the network - it is meant to be a
>> protection mechanism for compliant, truthful and as yet

True the NEA doesn't "do" anything to protect against compromised devices
but it does assist in limiting the known compromises on endpoint devices by
being a mechanism for the checking and reporting on compliance to what ever
network policy is in place including virus and patch levels.  As a network
administrator I already deploy mechanisms for doing just this, but at a
higher level than the NEA charter indicates.  To me the difference is
between being reactive or proactive.  Compliance testing I already run
occurs after an end node has joined the network, with NEA the possibility is
for compliance checking before being allowed onto the network so isolation
and immediate remediation is possible.

>> Any network, in its own best interests, must assume that it
>> has lying and compromised endpoints connecting to it and
>> that there are unknown vulnerabilities on any NEA-compliant
>> devices connecting to it. Any kind of protection that
>> addresses these general threats that the network may be
>> exposed to at any time will simply obviate the need for NEA from the
>> network perspective. 

Reliance on one protection or reporting mechanism is not enough.  We need a
lot of varied tools to cover all the bases and minimise risk.

>> A network operator that thinks the network is getting any
>> protection by employing NEA is clearly ignoring the obvious
>> real threats that the network is exposed to at any time.

No, NEA would just be one more tool used to improve overall security and
minimise risk.  It would be at a different level to the tools some of
already deploy.

>> This is what I meant when I said that the charter is unclear
>> and it must explicitly state that NEA is not meant as a
>> protection mechanism of any sort for the network.

I don't believe the Charter needs to delve into this at all.  If some people
see it as part of their protection mechanisms, so be it.

Darryl (Dassa) Lynch

---

From: Ted Hardie <[email-masked]>
Date: Sun, 8 Oct 2006 23:45:37 -0700

I have a very basic fear that this working group is getting chartered
with a bunch of aims added by people who will not take on the
task of doing the work.  After private discussion with folks
involved, my sense is that the very core of this work is a perceived 
need to be able to pass opaque strings between a host and the network 
prior to the host attaching.  Those opaque strings are, essentially,
the vendor-specific strings currently associated with posture assessment.
The standard protocol carrying these strings would connect on the network
side to a system that has plug-ins which understand the vendor-specific
strings.  

With a charter that clarified that this was intended to assist the end
systems with vulnerabilities prior to attachment because the
network they are attaching to might be filled with danger, I 
think this work would get done reasonably quickly. (As a control
mechanism to protect the network, I agree with the point made
clearly by others that this is not appropriate).

I am less sure of the task of standardizing attributes.

I am not sure that the number of attributes which can be standardized
will ever be high enough to be truly useful, and I am pretty sure
that all of these will be already covered by vendor-specific attributes.
Since there must be an assessor in place on the client for those few
standardized attributes to be assessed and that assessor will likely already
have these covered by vendor-specific attributes, in other words,
we seem to be standardizing redundancy.  On the network attachment
side, it is possible, of course, that an offer of remediation could be made
based on just the standard attributes, but it seems far more likely that
it would be a two step process (assess standard attributes, then pass
vendor-specific attributes to vendor plug-in).  Again, if the vendor's
attributes cover the standard attributes, then this is largely redundant
and may add measurable latency; it seems far more likely that 
step one would simply be skipped if there were a vendor-specific string
and an available plug-in. Since there has to be an assessor, the first
seems very likely to me.  If you don't have a vendor's plug-in, then
I suppose there is some chance that you will trust and act based on the standard
attributes, but the chance of getting the right remediation seems
pretty slight in those circumstances.  Especially when many vulnerabilities
are a combination of conditions, (Browser version Foo on OS patch level Bar) 
that you could remediate by upgrading either one, checking for and
acting on the attributes which could be standardized seems of very, very 
limited utility.

				Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Oct 2006 11:07:38 +0200

> see it as part of their protection mechanisms, so be it.

The IETF has an obligation to "truth in advertising" so IMHO we should not
claim protection that doesn't exist, even implicitly.

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 06:17:33 -0700

The IETF has an obligation to WIPO and to the DMCA and well - so far its
failed those pretty well I think.

Todd Glassey

---

From: "Fritz F. Saad" <[email-masked]>
Date: Mon, 9 Oct 2006 07:58:20 -0600

Tood,

Agreed, we should work to fix that.

Fritz.

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 7:17 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

Todd Glassey

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Oct 2006 16:31:34 +0200

> Agreed, we should work to fix that.
...
> The IETF has an obligation to WIPO and to the DMCA 
...

I can only assume this was intended as some form of joke.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 09 Oct 2006 11:03:33 -0400

> I can only assume this was intended as some form of joke.

regardless of intent, it should be treated as such.

Keith

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 09:08:42 -0700

No it wasn't Brian - the WIPO IP Framework calls for a set of protections
for Industrial Designs which ALL of the work that happens here is controlled
by right? Otherwise, do you formally want to make a declaration as the
IETF's Chair that the IETF and the ISOC are immune from Global IP Law and
can pretty much do anything they want.

Todd Glassey

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 09:05:50 -0700

Fritz this is a much bigger issue than ANYONE thinks at this time and its
based on the idea that the WIPO standard says that the IETF MUST be doing
Industrial Design IP Models, and it only does Copyright which is a violation
of the WIPO IP protection framework  and the treaties ALL of the Member
States have signed.

Interesting eh?

Todd Glassey

----- Original Message ----- 
From: "Fritz F. Saad" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 09, 2006 6:58 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 9 Oct 2006 10:36:10 -0700

On Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote:
> by right?

I suppose you might consider ALL IETF work as protected or threatened by
WIPO Inustrial Designs [1] treaties if you first accept that "ALL" IETF
work is ornamental.

But of course, the joke isn't funny if you have to explain it.

[1] http://www.wipo.int/designs/en/designs.html

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 15:09:31 -0400

> can pretty much do anything they want.

Todd,

According to the WIPO web site:

	"The World Intellectual Property Organization (WIPO) is a
	specialized agency of the United Nations. It is dedicated to
	developing a balanced and accessible international intellectual
	property (IP) system, which rewards creativity, stimulates innovation
	and contributes to economic development while safeguarding the public
	interest."

What the WIPO might or might not call for might perhaps be of interest
to various national legislative bodies, but it is completely out of
scope for the IETF list.

Regards,

					- Ted
					IETF Sergeant-at-Arms

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 13:54:51 -0700

No you are wrong Ted, and its pretty funny too.  As it happens you are
incorrect for saying that this is inappropriate for the IETF's lists.

You need to dig farther into the WIPO Site and find all the State Signatures
to the Treaties - its them that the IETF is bound by whether it likes it or
not.  Since the countries through with the IETF's actions operate including
the meetings, are all signatories to the WIPO Treaties you are exactly stuck
with them.

Todd Glassey

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 09, 2006 12:09 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 17:25:55 -0400

> the meetings, are all signatories to the WIPO Treaties you are exactly stuck

I said it was inappropraite for the IETF list.  If you have specific
ideas as they relate to the ipr working group, feel free to be
specific about specific WIPO treaties that have resulted in national
legislation, and specific changes to be made to IETF's IPR policies,
feel free to make them on that list, but not on the main IETF list,
please.

Thanks,

					- Ted

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 14:39:46 -0700

So then Ted are you formally saying that it is inappropriate to discuss IETF
operations or its processes on the [email-masked] mailing list?

The problem with the IPR working group is simply that Harald kicks people
off for disagreeing with him or his very limited charter. He doesn't want to
hear about expanding the charter or how these other issues fit into the IPR
Working Group and in doing so he is violating my and others participatory
rights as well as our First Amendment rights I believe too.

Todd Glassey.

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 09, 2006 2:25 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 14:39:46 -0700

Todd Glassey.

----- Original Message ----- 
From: "Theodore Tso" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>;
<[email-masked]>

---

From: Theodore Tso <[email-masked]>
Date: Mon, 9 Oct 2006 18:16:49 -0400

> operations or its processes on the [email-masked] mailing list?

If you have a specific and actionable suggestion regarding IETF
direction, policy, meetings, and procedures, where there is not a more
appropriate e-mail venue (such as the IPR wg list), then it is
certainly, appropriate for the IETF list.

Your recent postings, alas, have not met this test.

> rights as well as our First Amendment rights I believe too.

First Amendment rights only apply when the US Government restricts
speech.  It does not apply anywhere else.  In general, you have been
making various legal claims without being a lawyer, and fairly wild
ones which make it very clear that you don't know what you are talking
about.  For what it's worth, be advised that I know of know legally
enforceable "right" that you might have towards participating in any
IETF forum, and certainly if you persist in sounding like someone who
does not know what they are talking about, no one is required to
listen to you, either --- and more and more people may in fact decide
that it is wise for them to exercise their right to ignore you.

Regards,

						- Ted

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 17:04:14 -0700

You know Ted you crack me up.

Todd Glassey

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 9 Oct 2006 20:41:00 -0700

Hi -

Functionally, how would nea be different from using netconf
or snmp to retrieve a system's configuration data?  Describing
it as a way to retrieve vendor-specific strings from a system
makes it sound like a profile of netconf.

Randy

> From: "Ted Hardie" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, October 08, 2006 11:45 PM
> Subject: WG Review: Network Endpoint Assessment (nea)
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 10 Oct 2006 08:59:15 +0200

To qualify for protection, an industrial design must be aesthetic, 
and I believe that elegant design should be one of our goals in protocol
design.

However, industrial designs are "divorced from all technical aspects of
the article",
and thus at least some small portion of our ongoing work may be
ineligible for protection.

A major obstacle to be overcome before applying for design protection
for our work 
is the fact that ASCII RFCs can not contain lines or colors,
and would probably be rejected by the appropriate national offices.

Finally, please note the treaties:
   Terribly Complex Protection for Intellectual Property (TCP/IP)
   Ugly Dumb Protection for Intellectual Property (UDP/IP)
may directly impact our work.

Y(J)S

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Oct 2006 06:18:42 -0700

Yaakov - Did you cut that from Nolo's site - they are good people.

My argument is that the negotiation of the protocol inside the IETF's
vetting process is identical to two engineers arguing and then coming to a
new aesthetic implementation, its the new fenders for the truck., or a new
warning buzzer when the protocol fails step two - whatever step two was.

Don't confuse the term aesthetic here to mean something that it doesn't - or
to limit the process of the Utility Patent protection to things that you
'look at'.

Likewise, design patents (as opposed to plant patents) could also be used
and probably with better luck, but there is more cost to issuing and
researching/prosecuting the claims therein.

FWIW I initially tried to fit the design model into the Copyright Alone
model and couldn't.  I needed at least the Patent processes "Aesthetic
Design" provisions to make this all work. And yes I agree that the IETF's
processes are probably better covered under a comprehensive patent and
publishing rights process - something it isn't terribly interested in doing
apparently.

As to the rest of the Open Source world that has relied on these copyright
alone licenses, and with much pain and suffering too - look at the latest
revision to the EFF's license...

And all of this leads me to believe that more and more opensource code is
unpatentable and unprotectable as such. If it is the intent of this
management team to take the IETF to where it provides something close to
Open Source services then we have a real problem I think since no one
bothered to disclose this to the rest of the membership or those
contractually bound to the IETF in their participation agreements, which
IMHO is a real issue.

As to the reliance From [email-masked] Tue Oct 10 09:29:31 2006
From: "todd glassey" <[email-masked]>
To: "Yaakov Stein" <[email-masked]>,
	<[email-masked]>
Date: Tue, 10 Oct 2006 06:18:42 -0700
Cc: 
Subject: Re: WIPO issues (was: Network Endpoint Assessment (nea))

Yaakov - Did you cut that from Nolo's site - they are good people.

My argument is that the negotiation of the protocol inside the IETF's
vetting process is identical to two engineers arguing and then coming to a
new aesthetic implementation, its the new fenders for the truck., or a new
warning buzzer when the protocol fails step two - whatever step two was.

Don't confuse the term aesthetic here to mean something that it doesn't - or
to limit the process of the Utility Patent protection to things that you
'look at'.

Likewise, design patents (as opposed to plant patents) could also be used
and probably with better luck, but there is more cost to issuing and
researching/prosecuting the claims therein.

FWIW I initially tried to fit the design model into the Copyright Alone
model and couldn't.  I needed at least the Patent processes "Aesthetic
Design" provisions to make this all work. And yes I agree that the IETF's
processes are probably better covered under a comprehensive patent and
publishing rights process - something it isn't terribly interested in doing
apparently.

As to the rest of the Open Source world that has relied on these copyright
alone licenses, and with much pain and suffering too - look at the latest
revision to the EFF's license...

And all of this leads me to believe that more and more opensource code is
unpatentable and unprotectable as such. If it is the intent of this
management team to take the IETF to where it provides something close to
Open Source services then we have a real problem I think since no one
bothered to disclose this to the rest of the membership or those
contractually bound to the IETF in their participation agreements, which
IMHO is a real issue.

As to the reliance on  a copyright statement alone to cover the IETF's use,
that is IMHO broken. The IETF's reliance on "That there must be two
physically interoperable ports of any protocol" implemented to meet the
Standards Practice takes this out of the Copyright alone Area and creates
that Industrial Design that has to be protected.

My point to the Aesthetic Patent was that it was a tad easier to deal with
IMHO.

Todd Glassey

----- Original Message ----- 
From: "Yaakov Stein" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 09, 2006 11:59 PM
Subject: RE: WIPO issues (was: Network Endpoint Assessment (nea))

Y(J)S

---

From: "Kyse Faril" <[email-masked]>
Date: Tue, 10 Oct 2006 08:49:29 -0600

http://www.kulefornia.blogspot.com

ALL RIGHTS RESERVED

>Date: Tue, 10 Oct 2006 08:59:15 +0200
>
>

_________________________________________________________________
Try the new Live Search today!  
http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&FORM=WLMTAG

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Oct 2006 11:37:49 -0700

Hey Ted - the more I thought about this post of yours the more it annoyed
me. You see - when a WG chair doesn't want someone saying something in their
WG and they control the number of players in that WG, they will always
control the consensus such as it is.

The point is that there is no where to permanently register a dissenting
opinion in an effort or IETF program now that you claim that the charter for
the [email-masked] mailing list is restricted.

The IETF needs IMHO one general list for everything that doesn't fall under
the rubric/charter/umbrella of some WG and their list, and personally after
NETWORK was shutdown I thought that this was it.

Todd Glassey

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2006 14:34:51 -0500

Todd,

I've received several complains from people that think that you are crossing
the limit again and being off-topic with this thread and I seriously agree
with them.

Consequently I warn you. If you keep going on this, I will apply a new ban
(two weeks, as it will be your second one in a very short period of time).

Regards,
Jordi, acting as IETF Sergeant-at-arms

> De: todd glassey <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 10 Oct 2006 11:37:49 -0700
> Para: Theodore Tso <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, <[email-masked]>
> Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Oct 2006 12:42:30 -0700

Who filed the complaints? if you are accusing me of something I have the
right to know of what  I am accused and by whom.

Todd Glassey

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: "todd glassey" <[email-masked]>; <>
Cc: <[email-masked]>
Sent: Tuesday, October 10, 2006 12:34 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> >>> So then Ted are you formally saying that it is inappropriate to
discuss
> > IETF
> >>> hear about expanding the charter or how these other issues fit into
the
> > IPR
> This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2006 16:11:56 -0500

Todd,

People got very irritated with this type of messages and actually even
complain why I'm not more strict. I got at the time being already 3 new
complains after this message and obviouly I don't need to justify to you who
is complaining.

Clearly you crossed the line once more, and it took you only a few seconds
after getting my warning, so just instructed the secretariat to ban you for
two weeks from now.

And please, understand that I don't have anything personal, just fulfilling
my mission.

Regards,

> Fecha: Tue, 10 Oct 2006 12:42:30 -0700
> Para: <[email-masked]>, <[email-masked]>, "Contreras, Jorge"
> <[email-masked]>

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Oct 2006 16:51:22 -0700

Yes actually you do -how does anyone complained against know who is
complaining or why? - if the complaints are not public then the oversight is
not real - its a paper fiction - a lie in print.

Speaking of lies in print this is why IETF complaints are addressed and
penalties for them assessed before the appeal can be resolved - because the
IETF's oversight policy and practice model is ineffective and setup to allow
the IETF to exact whatever penalties it wants from individuals without the
benefit of the appeal or the appeal process.

So YES I want to know specifically who complained.

Todd Glassey

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 10, 2006 2:11 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> >>> opinion in an effort or IETF program now that you claim that the
charter
> > for

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 10 Oct 2006 17:10:50 -0700

I'm sorry to enter this fray, but I'd like to point out that while I
respect Todd's request to know who is accusing him and why, the rest of
us don't need to be copied that information. In fact, it is better that
we aren't copied because to do so would be unfair to the complainer(s).

Discipline is a difficult task to do fairly and because of this there
are many advantages in respectfully permitting the protagonists to have
privacy during key parts of the process.

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 4:51 PM
To: [email-masked]; [email-masked]
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

Yes actually you do -how does anyone complained against know who is
complaining or why? - if the complaints are not public then the
oversight is not real - its a paper fiction - a lie in print.

Speaking of lies in print this is why IETF complaints are addressed and
penalties for them assessed before the appeal can be resolved - because
the IETF's oversight policy and practice model is ineffective and setup
to allow the IETF to exact whatever penalties it wants from individuals
without the benefit of the appeal or the appeal process.

Todd Glassey

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 10, 2006 2:11 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> complain why I'm not more strict. I got at the time being already 3 
> new complains after this message and obviouly I don't need to justify 
> to you
who
> is complaining.
>
> Clearly you crossed the line once more, and it took you only a few 
> seconds after getting my warning, so just instructed the secretariat 
> to ban you
for
> > Para: <[email-masked]>, <[email-masked]>, "Contreras, 
> > Jorge" <[email-masked]>
> > Who filed the complaints? if you are accusing me of something I have

> > the right to know of what  I am accused and by whom.
> >
> > Todd Glassey
> >
> >> the limit again and being off-topic with this thread and I 
> >> seriously
agree
> >> with them.
> >>
> >> Consequently I warn you. If you keep going on this, I will apply a 
> >> new
ban
> >>> me. You see - when a WG chair doesn't want someone saying 
> >>> something in
> > their
> >>> WG and they control the number of players in that WG, they will 
> >>> always control the consensus such as it is.
> >>>
charter
> >>> The IETF needs IMHO one general list for everything that doesn't 
> >>> fall
> > under
> >>> the rubric/charter/umbrella of some WG and their list, and 
> >>> personally
> > after
> >>>>> The problem with the IPR working group is simply that Harald 
> >>>>> kicks
> >>> people
> >>>>> off for disagreeing with him or his very limited charter. He 
> >>>>> doesn't
> >>> want to
> >>>> First Amendment rights only apply when the US Government 
> >>>> restricts speech.  It does not apply anywhere else.  In general, 
> >>>> you have been making various legal claims without being a lawyer,

> >>>> and fairly wild ones which make it very clear that you don't know

> >>>> what you are
talking
> >>>> about.  For what it's worth, be advised that I know of know 
> >>>> legally enforceable "right" that you might have towards 
> >>>> participating in any IETF forum, and certainly if you persist in 
> >>>> sounding like someone who does not know what they are talking 
> >>>> about, no one is required to listen to you, either --- and more 
> >>>> and more people may in fact decide that it is wise for them to 
> >>>> exercise their right to ignore you.
> >>>>
> >>>> Regards,
> >>>>
> >>>> - Ted
> >>>
> >>>
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the contents
of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2006 19:45:48 -0500

Hi Eric,

I don't really agree with that. I've first the obligation to keep the
privacy about any email received in private. Of course, I can always suggest
that the people which complained in private speak up in the list, but I
don't think that noise will help anyone.

If there is a need to review my decision, the body in charge of that
"appeal" will have the information about those complains, of course.

If we as a community, feel that this should work in a different way, we
probably need to document/update the process used by the sergeant-at-arms.

Regards,
Jordi

> De: "Fleischman, Eric" <[email-masked]>
> Fecha: Tue, 10 Oct 2006 17:10:50 -0700
> Para: todd glassey <[email-masked]>, <[email-masked]>,
> <[email-masked]>
> Conversación: [Nea] WG Review: Network Endpoint Assessment (nea)
> Asunto: RE: [Nea] WG Review: Network Endpoint Assessment (nea)
> 
> aware

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Theodore Tso <[email-masked]>
Date: Tue, 10 Oct 2006 23:12:43 -0400

> "appeal" will have the information about those complains, of course.

Note that while we may use complaints from the community about whether
or not postings are inappropriate, in the end it is up to the
Sergeant-at-Arms about whether or not postings are appropriate and
form a pattern of abuse.  And the postings from the accused are
publically available on mailing list archives, and can be judged on
their own (dis-)merits.  For that reason, I don't believe that there
is any need to reveal private communications about complaints, since
the in the end, the final determination is and can be made by the
postings in isolation.

That being said, we do periodically check in with the IETF Chair, who
appointed us and has the power to dismiss us, whether or not in his
opinion, we are using the appropriate trigger levels for enforcing
violations of RFC 3005.

Regards,

					- Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 11 Oct 2006 01:01:33 -0700

Just FTR (and changing the subject, since this is not about NEA at all):

I agree with the principle that the sergeants-at-arms are obliged to 
make up their own minds about whether or not a posting is inappropriate, 
and that they are responsible for their own decisions.

Complaints are a means of calling their attention to a situation, 
nothing more.
An IETF participant should not have to suffer rants and threats from a 
suspended person in his private email inbox just because he commented to 
a sergeant-at-arms that he found the person's postings offensive.

I think the sergeants-at-arms have made the right call.

                    Harald, who gets the rants anyway

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Oct 2006 06:36:29 -0400

--On Tuesday, 10 October, 2006 16:51 -0700 todd glassey
<[email-masked]> wrote:

> Yes actually you do -how does anyone complained against know
> who is complaining or why? - if the complaints are not public
> then the oversight is not real - its a paper fiction - a lie
> in print.
>...

Todd,

While I'm reluctant to be sucked into this discussion, I think
your note shows a misunderstanding that needs to be clarified...
for the benefit of others, if not yours, because I don't think
you are listening (my personal opinion, only).

There seems to be a misunderstanding here in which the logic
goes as follows:

	(1) The IETF and its actions are legislative, judicial,
	or administrative procedures under the law of some
	country, usually the US.
	
	(2) Since (1) is true, there are specific rules that
	apply and rights that derive from those rules.
	
	(3) Those rules or rights are being violated.

Fortunately or unfortunately, the first premise is false.
Because it is false, the second is meaningless and the third
irrelevant. Just like every other standards development body
that operates in the US but one, the IETF is a private
organization with voluntary participation.  And, just like all
of the others whose standards are not directly concerned with
safety, health, or regulatory matters, use of its standards are
voluntary.   Nothing the IETF does falls directly into the
safety, health, or regulatory areas as those are normally
understood.  Even if some IETF standards or recommendations were
incorporated into legislation or rule-making by other bodies,
that would not change the status of the IETF itself any more
than it has changed the status of other voluntary
standards-making bodies.

I believe that you have two, and only two, fundamental rights in
the IETF that do not derive directly from procedures adopted by
the IETF and that the IETF can change.   The first of those is
to take any standardization (or other) work you want done
elsewhere, having it discussed and, if appropriate approved,
under the voluntary rules of that voluntary body (unless the
organization you choose or the topic fall under one of the
exception cases).  And the second is to try to convince others
to join you in your opinion that the IETF is not sufficiently
fair and balanced (or for whatever real or imaginary reasons you
like) that anyone should pay attention to its standards and
recommendations.  In neither case does the IETF has any right or
capability to interfere with your actions.

There are, of course, some edge-case exceptions.  If you and
other members of some protected group were being systematically
discriminated against, you might have some special rights (I
stress "might", because that would swiftly become a matter for
lawyers and judges and, like you, I am neither).   In addition,
if the IETF were actively and/or effectively acting in a way
that restrained trade or prevented competition in ways that
impacted you, you would have certain rights, differing by
country, and ways to seek remedies.  However, those remedies and
the methods for seeking them, would lie outside the IETF and its
processes.

You don't have the "right" to know who complained because:

(1) Nothing in the IETF procedures gives you that right.   While
Jordi might start a paragraph with a comment to the effect that
several people complained, he could equally have started it with
"it came to me in a dream last night": the two would have equal
effect since the procedures give the sergeant(s)-at-arms the
authority and obligation to make these determinations and do not
specify the ways in which they make them... other than
specifying some criteria and encouraging them to look at
patterns.

(2) As mentioned above, this is not a judicial or administrative
procedure from which additional right flow.

> ...
> whatever penalties it wants from individuals without the

As has been pointed out, you have the right to discuss the
general behavior of the sergeant(s)-at-arms with the IETF Chair.
You have the right to complain about their decisions directly to
the IAB (per RFC 3005).  But you have both of those rights
because, and only because, the IETF's procedures give them to
you.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Oct 2006 14:24:23 +0200

> opinion, we are using the appropriate trigger levels for enforcing

And the Chair's opinion is that the Sergeants are using a light touch
and are generally tolerant of a wide range of discourse.

I would however repeat once again that the easiest way to deal with
irrelevant mail is the Delete button. It's quicker than the Reply
button and has fewer unintended side effects.

     Brian

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 11 Oct 2006 10:09:36 -0400

> privacy during key parts of the process.
As much as I've sparred with Glassey in the past (I suspended him from a
WG mailing list, and was the target of an appeal to the IESG by him), I
think he's right in this case.  In my opinion, any sort of disciplinary
action needs to be *perceived* as fair.  That may not be as much of an
issue here -- the public record of Todd's postings is appallingly clear --
but I think we do need to follow due process.

I do agree that the Sergeants-at-Arms can act on their own volition, but
if they do they should say so; that gives the community grounds to judge
their behavior.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Oct 2006 07:38:07 -0700 (PDT)

> I think the sergeants-at-arms have made the right call.

I agree with everything Harald says here. Analogies to court situations and the
notion of "facing your accuser" are IMO entirely inappropriate. A better
analogy is to the many mechansisms that exist in various other contexts for
providing tips, suggestions, recommendations and compliants. In many of these
cases anonymity is not only allowed, it is required.

I don't think this is a case where anonymity is absolutely required, but 
it is definitely beneficial.

				Ned

---

From: "todd glassey" <[email-masked]>
Date: Wed, 11 Oct 2006 09:24:46 -0700

So then Ned you are saying that the Management of the IETF can say anything
they want to on a list about several 'supposed' complaints and then act upon
them without any due process or any recourse -

Let me ask, do I annoy you that much that you would be willing to give up
your rights to recourse in a dispute or to even functionally dispute
something?

Todd Glassey

----- Original Message ----- 
From: "Ned Freed" <[email-masked]>
To: "Harald Alvestrand" <[email-masked]>
Cc: "Theodore Tso" <[email-masked]>; <[email-masked]>; "JORDI PALET MARTINEZ"
<[email-masked]>
Sent: Wednesday, October 11, 2006 7:38 AM
Subject: Re: Complaints and complainers (Re: [Nea] WG Review: Network
Endpoint Assessment (nea))

---

From: "todd glassey" <[email-masked]>
Date: Wed, 11 Oct 2006 09:34:53 -0700

----- Original Message ----- 
From: "Steven M. Bellovin" <[email-masked]>
To: "Fleischman, Eric" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 11, 2006 7:09 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> > we aren't copied because to do so would be unfair to the complainer(s).

Eric - then talk to the SOA's - they posted the commentary as public
notice - I just responded to it.

> think he's right in this case.

Scary thought that eh?

> In my opinion, any sort of disciplinary
> I do agree that the Sergeants-at-Arms can act on their own volition,

Cool - when was this capability specifically placed into the IETF's Charter
or the Job Description of the SOA? Who is accountable for that SOA's actions
(including the party that appoints them?) And can they create policy to 'fit
the moment' and if so how?

> but

And it also provides specific recourse in Courts against the IETF and that
individual and their Sponser.

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Oct 2006 09:07:03 -0700 (PDT)

> them without any due process or any recourse -

Noel expressed it better than either Harald or I did. He said:

  My reasoning is that the decision of
  whether or not to suspend should be based almost entirely on the target
  person's posts, so the identity (and, indeed, the number) of people
  complaining is basically irrelevant.

That is, the decision to suspend your posting rights should be based solely on
what you did, not on who pointed what out to whom. It should not matter if
there is one complaint, a thousand complaints, or no complaint at all.

And as you well know, you do have recourse through an appeal. Invidious
comments claiming you do not do not strengthen your position.

> your rights to recourse in a dispute or to even functionally dispute

Well, since you asked, Todd, you don't annoy me at all. I find many of your
postings to be, shall we shall say, amusing. But lack of annoyance doesn't mean
they're relevant. IMO many if not most of them are not.

				Ned

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 9 Oct 2006 10:41:51 -0700

Ted Hardie <[email-masked]> wrote on 10/08/2006 11:45:37 PM:

> [snip]
> my sense is that the very core of this work is a perceived
> prior to the host attaching.

      Yes, that is the essence of this work which is what we need to
remember and focus on. It will probably be applied for various purposes.

> Those opaque strings are, essentially,

      There seems to be confusion as two why people would want to do this.
In one sense we can protect things by not giving compromised endpoints
access to network-attached resources, including parts of the network
itself. This application has

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 9 Oct 2006 10:41:51 -0700

There seems to be confusion as two why people would want to do this.
In one sense we can protect things by not giving compromised endpoints
access to network-attached resources, including parts of the network
itself. This application has caused significant discussion as to the
security of the protocol and solutions using it, which promises to be a
subject of debate for the near future.

      Another way of looking at this is that it allows customers to use the
network to enforce endpoint compliance to policy and provide a convenient
"place" to challenge endpoints, collect data from them, thus providing an
audit trail.

> acting on the attributes which could be standardized seems of very, very

      Standardized VS vendor-specific attributes is not something that
needs to be solved today. Solutions can start with vendor-specific and
migrate toward a standard, if one develops, without changing the protocol.
The specification should not preclude the addition of standardized
attributes. IE the specification is like an alphabet, attributes are like
vocabulary. You can add new words without changing the letters.

>             Ted Hardie

Frank Yeh

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Oct 2006 15:43:11 -0400

>>>>> "Frank" == Frank Yeh <[email-masked]> writes:

    Frank> Standardized VS vendor-specific attributes is not something that needs to be
    Frank> solved today. Solutions can start with vendor-specific and migrate toward a
    Frank> standard, if one develops, without changing the protocol. The specification
    Frank> should not preclude the addition of standardized attributes. IE the
    Frank> specification is like an alphabet, attributes are like vocabulary. You can add
    Frank> new words without changing the letters.

One of the things coming out of the most recent BOF was a strong
desire for PA-level interoperability.  That can be accomplished
through standardized attributes or vendor-specific attributes that are
sufficiently well documented (and not subject to patents) that third
parties can implement collectors or analysis tools that interoperate
with the vendor tools for the vendor attributes.

Will we be able to meet these interoperability goals?  Why or why not?

---

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

Sam, 

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 12:43 PM
> To: Frank Yeh Jr
> Cc: Hardie, Ted; [email-masked]; [email-masked]
> One of the things coming out of the most recent BOF was a 
> strong desire for PA-level interoperability.  That can be 
> accomplished through standardized attributes or 
> vendor-specific attributes that are sufficiently well 
> documented (and not subject to patents) that third parties 
> can implement collectors or analysis tools that interoperate 

I am very apprehensive of achieving 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. 

Regards,
Vidya

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

> Will we be able to meet these interoperability goals?  Why or why not?

Yes, we can. If we define a small set of standardized attributes
(OS and app version, AV status, etc.) and make them mandatory to
implement, then we will have interoperability with respect to
those attributes. We should allow the definition of attributes
that go beyond this minimal standard mandatory to implement (MTI)
set but the MTI set will provide a baseline of information
available for all endpoints that implement NEA.

Thanks,

Steve

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

Thanks,

Steve

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

Thanks,

Steve

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 02:04:42 -0400

> to provide any acceptable level of security, even for the endpoints.

This is not surprising, since you have said that you don't see
any security value to NEA.

> attributes needed for any continued meaningful protection.  

NEA is not based on applications supporting attributes.
Attributes are supported by Posture Collectors and
Posture Validators, specialized NEA components. An AV
Posture Collector will handle attributes pertaining
to AV, perhaps by interfacing with an existing AV
application. Still, I agree that a given endpoint
will typically only support a small subset of the
universe of possible attributes. Not a problem.
As long as the endpoint supports enough attributes
that the Posture Broker can evaluate its compliance
with the posture policy, that's enough.

Thanks,

Steve

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 5:06 PM
To: Sam Hartman; Frank Yeh Jr
Cc: Hardie, Ted; [email-masked]; [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

Sam, 

> Will we be able to meet these interoperability goals?  Why or why not?

I am very apprehensive of [email-masked]>
To: "Narayanan, Vidya" <[email-masked]>,
	"Sam Hartman" <[email-masked]>, "Frank Yeh Jr" <[email-masked]>
Cc: "Hardie, Ted" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

> to provide any acceptable level of security, even for the endpoints.

This is not surprising, since you have said that you don't see
any security value to NEA.

> attributes needed for any continued meaningful protection.  

NEA is not based on applications supporting attributes.
Attributes are supported by Posture Collectors and
Posture Validators, specialized NEA components. An AV
Posture Collector will handle attributes pertaining
to AV, perhaps by interfacing with an existing AV
application. Still, I agree that a given endpoint
will typically only support a small subset of the
universe of possible attributes. Not a problem.
As long as the endpoint supports enough attributes
that the Posture Broker can evaluate its compliance
with the posture policy, that's enough.

Thanks,

Steve

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 5:06 PM
To: Sam Hartman; Frank Yeh Jr
Cc: Hardie, Ted; [email-masked]; [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

Sam, 

> Will we be able to meet these interoperability goals?  Why or why not?

I am very apprehensive of [email-masked]>
To: "Narayanan, Vidya" <[email-masked]>,
	"Sam Hartman" <[email-masked]>, "Frank Yeh Jr" <[email-masked]>
Cc: "Hardie, Ted" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

> to provide any acceptable level of security, even for the endpoints.

This is not surprising, since you have said that you don't see
any security value to NEA.

> attributes needed for any continued meaningful protection.  

NEA is not based on applications supporting attributes.
Attributes are supported by Posture Collectors and
Posture Validators, specialized NEA components. An AV
Posture Collector will handle attributes pertaining
to AV, perhaps by interfacing with an existing AV
application. Still, I agree that a given endpoint
will typically only support a small subset of the
universe of possible attributes. Not a problem.
As long as the endpoint supports enough attributes
that the Posture Broker can evaluate its compliance
with the posture policy, that's enough.

Thanks,

Steve

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 5:06 PM
To: Sam Hartman; Frank Yeh Jr
Cc: Hardie, Ted; [email-masked]; [email-masked]
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

Sam, 

Regards,
Vidya

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Oct 2006 09:28:32 -0700

At 2:04 AM -0400 10/17/06, Stephen Hanna wrote:
>implement,

Sorry, but doesn't "AV status" above refer to the existing, proprietary anti-virus
systems?  How does standardizing an attribute for carrying that help
create a standardized understanding of what it means?    Don't I still
have to treat that as, essentially, a vendor attribute, since I have
to know which vendor statuses cover which vulnerabilities?

Or do you mean "there is some anti-virus software here"?

			Ted Hardie

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Oct 2006 20:22:57 +0200

Ted,
> Or do you mean "there is some anti-virus software here"?
I would think that five or six values are appropriate:

   1. Vendor name (string)
   2. Vendor engine version (integer)
   3. Vendor virus definitions version (integer)
   4. Enabled? (binary)
   5. Buggered? (binary)
   6. Other gobbledigook the vendor wants to include that might get
      standardized later. (blob)

I could envision 3 being a bit of an issue if it is possible to update 
specific viruses but not others.

I would expect the normal enterprise administrator to be able to act on 
the first 5.  The 6th is there as a placeholder.  I'm not sure I'd trust 
5 if it's false.  I'd also suggest we're well into solving the problem 
at this point.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Oct 2006 12:25:01 -0700

At 8:22 PM +0200 10/17/06, Eliot Lear wrote:
> would think that five or six values are appropriate:
>
>  1. Vendor name (string)
>I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others.

Thanks for this.  I was assuming we were talking primarily about a "1 and 3" combined
value.  As it stands now, you need access to the vendor's database to know what
viruses are covered by any specific version (your 3).  For the charter discussions,
I want to know whether it will be an aim of the working group to standardize:

* a way of carrying this information
* the structure of this information (but not its content)
* a standard representation of the content, so that access to the vendor database
   is no longer required

The tasks are substantially different in scope, and the level of interoperabilty
the community can expect from them are similarly different.
			regards,
				Ted Hardie

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Oct 2006 15:07:26 -0700

>      standardized later. (blob)

This still seems like too much.  Information offered for access can  
be contained within one or more certificates.   The information  
within these certificates should be limited to a minimal set of values:

1) creator
2) class
3) user-host
4) time-stamp
5) update resources

The essential information would be the creator/class/user-host/time- 
stamp fields.  When protection is not enabled or is buggered, then a  
newer certificate should not be offered.  The virus definitions or  
patch updates can be deduced from the time-stamp or by extensions  
added to class, i.e. AVX-VISTA-37.  If a vulnerability is reported  
subsequent to the time-stamp regarding the creator/class of service,  
then a new certificate could be required.  This would simplify  
tracking at the access point.  By keeping the information exchanged  
and decisions limited to this minimal information, NEA should provide  
a valuable services in many environments.

Perhaps there should be some consideration given regarding which sets  
of certificates are offered in various environments.  Allowing the  
certificates to be accessed beyond an authentication process seems to  
increase security exposures.  As this information is not trustworthy,  
there would be also little gained sharing this information  
elsewhere.  In fact, sharing this information may increase infection  
rates when this aids malware.

-Doug

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Oct 2006 10:37:22 -0400

>>>>> "Douglas" == Douglas Otis <[email-masked]> writes:

    Douglas> This still seems like too much.  Information offered for
    Douglas> access can be contained within one or more certificates.
    Douglas> The information within these certificates should be
    Douglas> limited to a minimal set of values:

    Douglas> 1) creator 2) class 3) user-host 4) time-stamp 5) update
    Douglas> resources

    Douglas> The essential information would be the
    Douglas> creator/class/user-host/time- stamp fields.  When
    Douglas> protection is not enabled or is buggered, then a newer
    Douglas> certificate should not be offered.  The virus definitions
    Douglas> or patch updates can be deduced from the time-stamp or by
    Douglas> extensions added to class, i.e. AVX-VISTA-37.  If a
    Douglas> vulnerability is reported subsequent to the time-stamp
    Douglas> regarding the creator/class of service, then a new
    Douglas> certificate could be required.  This would simplify
    Douglas> tracking at the access point.  By keeping the information
    Douglas> exchanged and decisions limited to this minimal
    Douglas> information, NEA should provide a valuable services in
    Douglas> many environments.

How do I get a new cert if mine is expired?  Go for remediation and
get it there?

I actually like a lot of what you specify.

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 19 Oct 2006 10:44:23 -0400

Ted Hardie wrote:
> For the charter discussions, I want to know whether it will
> be an aim of the working group to standardize:
>

I believe that we'll need to define all three of these.
There may be times when access to an external database
would be useful (if you want to know exactly which viruses
are covered by which AV defs version, for example) but
such access should not be required to use the standard
attributes.

Thanks,

Steve