Re: [midcom] security recommendations in MIDCOM MIB draft
Wes Hardaker <wjhns1@hardakers.net> Fri, 13 July 2007 13:57 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 1I9LeE-00037t-T6; Fri, 13 Jul 2007 09:57:30 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LeD-00036x-5X for midcom@ietf.org; Fri, 13 Jul 2007 09:57:29 -0400
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9LeC-0002oB-RO for midcom@ietf.org; Fri, 13 Jul 2007 09:57:29 -0400
Received: by wes.hardakers.net (Postfix, from userid 274) id 609F62C3604; Fri, 13 Jul 2007 06:58:03 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Melinda Shore <mshore@cisco.com>
Subject: Re: [midcom] security recommendations in MIDCOM MIB draft
Organization: Sparta
References: <C2BBC39F.25684%mshore@cisco.com>
Date: Fri, 13 Jul 2007 06:58:03 -0700
In-Reply-To: <C2BBC39F.25684%mshore@cisco.com> (Melinda Shore's message of "Thu, 12 Jul 2007 11:40:15 -0400")
Message-ID: <sdk5t4flsk.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.19 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: midcom@ietf.org, Tim Polk <tim.polk@nist.gov>, Wes Hardaker <wjhns1@hardakers.net>
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
>>>>> "MS" == Melinda Shore <mshore@cisco.com> writes: MS> On 7/12/07 7:51 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> MS> 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. MS> The starting point is: requesting services from a middlebox must MS> be secure. If that's to be done cryptographically, it requires MS> SNMPv3. I think the text needs to require one method be available to operators consistently across all the devices they purchase. If they choose not to use it because they have other methods of securing their traffic they're comfortable with, then so be it. But at least they should be sure they can use one method. Something like: MIBCOM devices MUST implement SNMPv3 to allow for operators to rely on it's features in order to protect their traffic. Operators should use make use of SNMPv3, other protocols providing cryptographic protection or physical separation to to ensure MIBCOM traffic is secured. -- Wes Hardaker Sparta, Inc. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom
- [midcom] security recommendations in MIDCOM MIB d… Juergen Quittek
- Re: [midcom] security recommendations in MIDCOM M… Lars Eggert
- Re: [midcom] security recommendations in MIDCOM M… Lars Eggert
- Re: [midcom] security recommendations in MIDCOM M… Magnus Westerlund
- Re: [midcom] security recommendations in MIDCOM M… Juergen Quittek
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker
- Re: [midcom] security recommendations in MIDCOM M… Magnus Westerlund
- Re: [midcom] security recommendations in MIDCOM M… Melinda Shore
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker
- Re: [midcom] security recommendations in MIDCOM M… Melinda Shore
- Re: [midcom] security recommendations in MIDCOM M… Wes Hardaker