Subject: RE: [Nea] IETF67 NEA WG Meeting summary

From: "Fergie" <[email-masked]>
Date: Thu, 9 Nov 2006 19:10:17 GMT

Agreed -- overlooking the consumer market would be a serious
oversight, methinks.

- ferg

-- Khaja Ahmed <[email-masked]> wrote:

To reiterate a point I made in the meeting, and to prompt some
discussion on it...

I am not sure what the value is of restricting the charter to solving
the problem for enterprises only.  The internet includes home networks.
Why leave them out?  In fact, as the 'Internet' engineering task force,
we should ensure that all of the internet can benefit from whatever
protocols / solutions we design.  

I recommend that we add a home user scenario as well.  

Having discussed this with ISPs like Verizon, SBC, etc, they want to
provide nea as a value-add, optional, service to consumers.  Consumers
benefit, the internet benefits and I suspect the enterprise benefit.  It
doesn't help to ensure that the enterprise networks are healthy if the
internet is slammed because of larger numbers of home users have poorly
managed / administered systems.  

It may be the case what works for enterprises will happen to work for
home users getting such services from ISPs but I'd prefer that we make
it easier to accomplish this by making it an explicit goal.  

Khaja

-----Original Message-----
From: Susan Thomson (sethomso) [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 10:32 AM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Nea] IETF67 NEA WG Meeting summary 

NEA WG Meeting Summary 
Tuesday Nov 7 15.20-17.20

1. Discuss formation of NEA WG Requirements I-D

The first milestone of the WG is formation of the requirements I-D. To
this end, the contents that need to be covered in the Requirements I-D
were reviewed along with the proposed reference model.  Several use
cases were introduced with the goal of driving protocol requirements.  

The WG also reviewed an individual submission on NEA requirements that
had been submitted prior to chartering of the WG. Some material in this
document may be used as a start for the WG document with appropriate
changes to reflect the approved charter.

2. Next Steps:

WG chairs to send call for requirements I-D "design team" volunteers  to
mailing list (done)
Volunteers to send names to WG chairs by Nov 16
WG chairs to select design team by Nov 22
Design team to start con calls week of Nov 27
Post first draft of requirements I-D 

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

---

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Thu, 9 Nov 2006 15:04:38 -0500

I am removing secdir mailing list from the thread since they should not
have been cc'ed in the first place. My mistake.

Please keep discussions to this mailing list.

Thanks
Susan

> From: Fergie [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 2:10 PM
> To: [email-masked]
> Cc: Susan Thomson (sethomso); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Nea] IETF67 NEA WG Meeting summary 
>

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 13 Nov 2006 23:42:45 -0800

-----Original Message-----
From: Khaja Ahmed 
Sent: Monday, November 13, 2006 11:40 PM
To: Fergie; [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] IETF67 NEA WG Meeting summary

It seems certain that access to the network, at least from some ISPs,
will be conditional upon providing health information.  That is the
prerogative of the ISP.  

Users who do not want to provide ISPs information about their OS, patch
level, AV used, etc. will have to use ISPs who do not require this.  

Khaja

-----Original Message-----
From: Fergie [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 11:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] IETF67 NEA WG Meeting summary

-- "Darryl \(Dassa\) Lynch" <[email-masked]> wrote:

>Couldn't the solution be as simple as allowing the client nodes the
option
>of deciding what information they are prepared to make available and
the
>network then using what is available to decide how they should be
treated?
>If not enough information is provided the node can be shunted off for
some
>form of remediation, if the network deems it has enough information
then the
>node can be allowed in.
>
>Both parties have choices then, what information to provide and what is
>required to be accepted.  
>

It is my understanding from the WG charter that a primary benefit
of NEA is that an administrative entity should be able to determine
the posture of an end-system without the end-systems consent (of
course, there may indeed be reasons why the opposite would be true,
too).

It would seem to me that if the end-system has the ability to
nullify that ability, then NEA would be pretty worthless.

In any event, the charter says:

"The PB (Posture Broker) protocol aggregates posture attributes
from one or more Posture Collectors in an NEA client and sends
them to the NEA server for assessment by one or more Posture
Validators."

Having read that, it would appear the issue of assessing posture
is one that is done between the the Posture Validator(s) and the
Posture Broker (where Posture attributes are aggregated), not
the NEA end-system (client) directly.

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 14 Nov 2006 08:58:36 -0500

>nullify that ability, then NEA would be pretty worthless.

It's like Social Security numbers in USA. You may withhold your SSN when
you request a loan from a bank. In which case the bank will exercise its
rigth to reject your loan application. :-)

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 09:15:33 -0500

> An example I can imagine is where a NEA enabled node attempts to connect and
> is requested to provide information on the current anti-virus status.  A yes
> or no answer can only be given where the policy is known and then a
> comparison made at the node to determine if the policy is met or not.  This
> shifts the onus of providing additional information to the network and away
> from the node which exposes some information that may be gleened for refined
> attack vectors.

good point.

> My personal choice is to limit the amount of information exposed by the
> network and leave the onus on the node to provide more as they are the ones
> requesting access.
> 
> If the attributes are defined carefully it should be possible to reach a
> reasonable compromise.

perhaps, though that might be a bit different than the charter 
anticipates, depending on whether that particular text is descriptive or 
proscriptive.

(IMHO, way too much is assumed by the current charter - it's a case of 
making engineering decisions before the problem is understood.)