Re: [midcom] security recommendations in MIDCOM MIB draft

Melinda Shore <mshore@cisco.com> Thu, 12 July 2007 15:40 UTC

Return-path: <midcom-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90md-00050l-0W; Thu, 12 Jul 2007 11:40:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90mc-0004xB-EO for midcom@ietf.org; Thu, 12 Jul 2007 11:40:46 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90mX-0006MC-Mf for midcom@ietf.org; Thu, 12 Jul 2007 11:40:46 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2007 11:40:23 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAITnlUZAZnme/2dsb2JhbAA
X-IronPort-AV: i="4.16,533,1175486400"; d="scan'208"; a="65010298:sNHT48915879514"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6CFeNWn011799; Thu, 12 Jul 2007 11:40:23 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6CFeFsa009751; Thu, 12 Jul 2007 15:40:23 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:40:18 -0400
Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jul 2007 15:40:18 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Thu, 12 Jul 2007 11:40:15 -0400
Subject: Re: [midcom] security recommendations in MIDCOM MIB draft
From: Melinda Shore <mshore@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Wes Hardaker <wjhns1@hardakers.net>
Message-ID: <C2BBC39F.25684%mshore@cisco.com>
Thread-Topic: [midcom] security recommendations in MIDCOM MIB draft
Thread-Index: AcfEmvD1L783JDCOEdyO5AAKleNSdA==
In-Reply-To: <469615B1.6040309@ericsson.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Jul 2007 15:40:18.0778 (UTC) FILETIME=[F33653A0:01C7C49A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1109; t=1184254823; x=1185118823; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20<mshore@cisco.com> |Subject:=20Re=3A=20[midcom]=20security=20recommendations=20in=20MIDCOM=2 0MIB=20draft |Sender:=20 |To:=20Magnus=20Westerlund=20<magnus.westerlund@ericsson.com>, =0A=20=20=2 0=20=20=20=20=20Wes=20Hardaker=20<wjhns1@hardakers.net>; bh=Tj/WPR+ildcrYWwd8OUhFh+ggdGNnrwwP0InVMa9lgM=; b=V+Zvv2bR5TjXC2Tj894whgV1elxl3Uedx2LWLikOUeuUMRtEf6MAzDJCzMtBJ/Ad2pktf64K P+ktNmi4fKrBWz48FRg4bqi34YDaf1SeG9kCwYQfTzxUcWfdXrGtyFjP;
Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: midcom@ietf.org, Tim Polk <tim.polk@nist.gov>
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org

On 7/12/07 7:51 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com>
wrote:
> Can we please come to consensus on this topic. And if there are text
> changes to implement the consensus, please provide them as RFC-editor
> notes to me.

The starting point is: requesting services from a middlebox must
be secure.  If that's to be done cryptographically, it requires
SNMPv3.  If it's not to be done cryptographically it suggests that
the protocol is being run over a "secure" network.  The latter was
not considered acceptable by the responsible area director at the
time that the work was ramping up, and it seems to me the question
of whether or not SNMPv3 is to be required hinges on whether or
not we can now permit an assumption of a "secure" network (for example,
running it over an IPSec tunnel).  It seems to me that if we
can't assume the use of a secure network in some deployments then
SNMPv3 has to be required, since sending firewall requests and
NAT answers insecurely is obviously unacceptable.  Do you think
the assumption of a secure network would pass review?

Melinda

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom