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

From: John Vollbrecht <[email-masked]>
Date: Thu, 26 Jan 2006 11:33:11 -0500

Brian and Mauricio -

Good dialog - A few comments below -

On Jan 25, 2006, at 10:50 AM, Brian Ford ((brford)) wrote:

>
> 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 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.

> 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.
>
>
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.

> 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?
>
>
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.

> Liberty for All,
> Brian

John

>
> -----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
>
>
>

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

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