Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Narayanan, Vidya wrote:
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.
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".
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.
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 poinFrom ietf-bounces at ietf.org Tue Oct 17 02:20:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZiBn-00025R-H8; Tue, 17 Oct 2006 02:12:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZiBa-0001ko-2S; Tue, 17 Oct 2006 02:12:22 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZi5q-0000d8-MI; Tue, 17 Oct 2006 02:06:28 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0D4162596C2;
	Tue, 17 Oct 2006 08:03:49 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 32674-05; Tue, 17 Oct 2006 08:03:44 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162])
	by eikenes.alvestrand.no (Postfix) with ESMTP id CC0022596AF;
	Tue, 17 Oct 2006 08:03:43 +0200 (CEST)
Message-ID: <453472DC.1020503 at alvestrand.no>
Date: Tue, 17 Oct 2006 08:06:20 +0200
From: Harald Alvestrand <harald at alvestrand.no>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan at qualcomm.com>
References: <C24CB51D5AA800449982D9BCB903251324206E at NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB903251324206E at NAEX13.na.qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: nea at ietf.org, ietf at ietf.org, Alan DeKok <aland at deployingradius.com>
Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

Narayanan, Vidya wrote:
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.
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".
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.
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 poinFrom ietf-bounces at ietf.org Tue Oct 17 02:20:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZiBn-00025R-H8; Tue, 17 Oct 2006 02:12:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZiBa-0001ko-2S; Tue, 17 Oct 2006 02:12:22 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GZi5q-0000d8-MI; Tue, 17 Oct 2006 02:06:28 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0D4162596C2;
	Tue, 17 Oct 2006 08:03:49 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 32674-05; Tue, 17 Oct 2006 08:03:44 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162])
	by eikenes.alvestrand.no (Postfix) with ESMTP id CC0022596AF;
	Tue, 17 Oct 2006 08:03:43 +0200 (CEST)
Message-ID: <453472DC.1020503 at alvestrand.no>
Date: Tue, 17 Oct 2006 08:06:20 +0200
From: Harald Alvestrand <harald at alvestrand.no>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan at qualcomm.com>
References: <C24CB51D5AA800449982D9BCB903251324206E at NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB903251324206E at NAEX13.na.qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: nea at ietf.org, ietf at ietf.org, Alan DeKok <aland at deployingradius.com>
Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

Narayanan, Vidya wrote:
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.
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".
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.
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


_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.