Subject: [Nea] RE: Comments on NEA Problem Statement

From: "Brian Ford \(brford\)" <[email-masked]>
Date: Wed, 25 Jan 2006 10:50:41 -0500

Mauricio,

Great message.

I disagree with your assessment that there are only three solutions that
need to be considered.  There are several very large and established
security vendors not represented there as well as a number of start ups.
Some of these others are bringing interesting alternatives to the table
in their solutions.

I don't believe section 1 of the problem statement defined an
architecture as much as it tried to put some bounds around what is out
there right now.

Given that this IETF effort is still in the early formative stages don't
you think we should refine the bounds and scope of the problem space
before we start to consider interoperability?

Liberty for All,

Brian 

-----Original Message-----

Date: Mon, 23 Jan 2006 13:53:26 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Subject: [Nea] Comments on NEA Problem statement
To: <[email-masked]>
Cc: Steve Hanna <[email-masked]>, [email-masked]

Finally had some time to look through the problem statement.  It's a
good start.  Look forwarding to working with the team to get this one
going...

Substantive comment #1: 
------------------------

We may want to reconsider the problem statement of NEA [section 3].
While I do agree there's a general endpoint integrity/posture problem
and solution, I don't agree that it is NEA's goal to solve this.  I see
the problem that NEA is trying to solve as one of interoperability, not
of functionality.  Customer's already have a functional solution for the
endpoint integrity/posture problem.  There is actually more than one
solution - I can think of three: Trusted Computing Group's Trusted
Network Connect, Cisco's Network Admission Control, and Microsoft's
Network Access Protection.  The problem with these solutions is that
they are not at all interoperable. This is where I see NEA providing
value by making some strides towards interoperability.

We have to be careful on pinning down the scope of NEA.  The document
tends to mix together the desire to make existing architectures more
interoperable through common protocols, but also takes the stance that
NEA *will* support a number of diverse goals [section 4] that may or may
not already be supported in existing architectures (i.e.).  My opinion
is the NEA should focus on assisting interoperability of what has
already been defined in existing architectures and leave the rest for a
different effort (or at least as a future goal and not an immediate
one). 

Moreover, the document spends a substantial amount of time creating new
nomenclature and describing a new generalized architecture, even though
it states up front [section 1] that it is not the intention of NEA to
create a new framework.  It seems that sections 2 through 6 have just
done that and do not reference in any implicit or explicit manner
existing architectures/efforts.  My suggestion on these sections would
be that they be more inclusive of existing architectures and discuss
from the perspective that we have existing solutions to the endpoint
integrity/posture problem, but they are currently incompatible and
non-interoperable due to differing use of protocols and protocol
bindings. 

What I see to be the real aim of NEA only shows up until section 7
(scope of standardization).  This section is good and could be improved
by describing how existing architectures would benefit from having these
interfaces standardized.  

Speaking of interfaces... It is probably a misnomer to call NEA a
standardization of various interfaces.  I see the work being more one of
standardization of protocol and/or protocol bindings. The term interface
may be construed as meaning API's , which should not be the intention. 

Substantive comment #2: 
-----------------------
Role of trusted computing technology is not highlighted in any form.
Although it shouldn't be mentioned as a normative reference, it should
be brought in a way that has it as an informative reference.

<snip>

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

------------------------------

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

End of Nea Digest, Vol 3, Issue 4
*********************************

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

---

From: John Vollbrecht <[email-masked]>
Date: Wed, 25 Jan 2006 17:04:55 -0500

Brian and Mauricio -

Good dialog - A few comments below -

> Some of these others are bringing interesting alternatives to the  
I think it would be good if others brought their solutions to the  
table.  Certainly IETF will provide an environment where all may be  
brought to the table and be considered.

It is my guess, however, that all  higher layer solutions have a  
significant amount in common in their architecture, and have common  
lower layer needs.  Again, in my opinion, it is these lower layer  
needs that make this interesting for IETF.  The architecture of each  
solution has needs for lower layer(s) that are appropriate for IETF  
to define.

Given this, I agree with Mauricio that the first sections seem to  
attempt to define (new) terminology and architecture and imply that  
this is the area where standardization is expected.

In my opinion, the new terminology does seem to be needed, but to  
provide a tool to show existing solutions compare and to use these  
real world/existing solutions to define a strong set of uses cases  
and requirements for standardizing lower layers.  If this is what is  
intended, then I suggest a statement that this is what is intended,  
and inviting others to share their architectures for the sake of  
creating use cases for defining requirements for standardization of  
the lower layer.

> architecture as much as it tried to put some bounds around what is out
I guess one could see this either way.  My first take was this was an  
attempt to create a architecture based on existing implementations.   
My question is whether implementors of existing solutions see these  
as useful in describing their implementation.

> before we start to consider interoperability?
I agree that we should have dialog about bounds and scope.  My  
comments are meant to be input to such a discussion.

I also think that the areas of interoperability that are included and  
how they are prioritized in terms of work items is important.  In my  
opinion the transport layer is the place where IETF standards are  
needed by all the existing implementations (I may be wrong) and that  
this is the highest priority area.

> Brian

John

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 25 Jan 2006 15:05:31 -0800

FYI. Just in case you have not seen these.

January 16, Monday - Working Group and BOF scheduling begins
February 13, Monday - Cutoff date for requests to schedule Working Group
and BOF meetings at 17:00 ET (22:00 GMT)
February 17, Friday - Preliminary agenda published for comment
February 20, Monday - Working Group Chair approval for initial document
(Version -00) submissions appreciated by 09:00 ET (14:00 GMT)
February 22, Wednesday - Cutoff date for requests to reschedule Working
Group and BOF meetings 09:00 ET (14:00 GMT)
February 27, Monday - Final Working Group and BOF agenda to be published
February 27, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (14:00 GMT)
March 6, Monday - Internet Draft final submission cut-off by 09:00 ET  
(14:00 GMT)
March 8, Wednesday - Pre-Registration and Pre-payment cut-off at 12:00  noon

ET (17:00 GMT)
March 13, Monday - Working Group agendas due date by 12:00 ET (17:00
GMT), upload using IETF Meeting Materials Management Tool
March 13, Monday - Registration cancellation cut-off at 17:00 ET (22:00 GMT)
March 19-24, 2006 - 65th IETF Meeting in Dallas, TX, USA

** Times are in US Eastern Time and GMT **