Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.txt

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Wed, 28 November 2012 15:55 UTC

Return-Path: <bertietf@bwijnen.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92D821F855A for <sidr@ietfa.amsl.com>; Wed, 28 Nov 2012 07:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15I5XUpp8aa4 for <sidr@ietfa.amsl.com>; Wed, 28 Nov 2012 07:55:58 -0800 (PST)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 833B121F8521 for <sidr@ietf.org>; Wed, 28 Nov 2012 07:55:58 -0800 (PST)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1TdjzP-0007bT-Aa; Wed, 28 Nov 2012 16:55:57 +0100
Received: from cat.ripe.net ([193.0.1.249] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1TdjzO-0006Ou-UN; Wed, 28 Nov 2012 16:55:55 +0100
Message-ID: <50B6340A.1060000@bwijnen.net>
Date: Wed, 28 Nov 2012 16:55:54 +0100
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>
References: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> <50B632F0.8080006@ieca.com>
In-Reply-To: <50B632F0.8080006@ieca.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121128 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a4d1f60df9d990327aebcbb02287adcf
Cc: sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 15:55:59 -0000

Mmm.. seems I even forget about such updates.
OK, I agree we should make that change.

Randy (Bush) do you want me to do that or will you do it?

Bert

On 11/28/12 4:51 PM, Sean Turner wrote:
> The MIB doctors approved a change to MIB security considerations:
>
> https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01369.html
> change here:
> https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01368.html
>
> Need to make the following change in the security considerations:
>
> OLD
>
>   SNMP versions prior to SNMPv3 did not include adequate security.
>   Even if the network itself is secure (for example by using IPsec),
>   even then, there is no control as to who on the secure network is
>   allowed to access and GET/SET (read/change/create/delete) the objects
>   in this MIB module.
>
>   It is RECOMMENDED that implementers consider the security features as
>   provided by the SNMPv3 framework (see [RFC3410], section 8),
>   including full support for the SNMPv3 cryptographic mechanisms (for
>   authentication and privacy).
>
> NEW
>
>   SNMP versions prior to SNMPv3 did not include adequate security.
>   Even if the network itself is secure (for example by using IPsec),
>   there is no control as to who on the secure network is
>   allowed to access and GET/SET (read/change/create/delete) the objects
>   in this MIB module.
>
>   Implementations MUST provide the security features described by the
>   SNMPv3 framework (see [RFC3410]), including full support for
>   authentication and privacy via the User-based Security Model (USM)
>   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
>   MAY also provide support for the Transport Security Model (TSM)
>   [RFC5591] in combination with a secure transport such as SSH
>   [RFC5592] or TLS/DTLS [RFC6353].
>
> and add some new informative references:
>
>   [RFC3414] Blumenthal, U., and B. Wijnen,
>             "User-based Security Model (USM) for version 3 of the
>             Simple Network Management Protocol (SNMPv3)", RFC 3414,
>             December 2002.
>
>   [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie,
>             "The Advanced Encryption Standard (AES) Cipher
>             Algorithm in the SNMP User-based Security Model",
>             RFC 3826, June 2004.
>
>   [RFC5591] Harrington, D., and W. Hardaker,
>             "Transport Security Model for the Simple Network
>             Management Protocol (SNMP)", June 2009.
>
>   [RFC5592] Harrington, D., Saloway, J., and W. Hardaker,
>             "Secure Shell Transport Model for the Simple Network
>             Management Protocol (SNMP)", June 2009.
>
>   [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport
>             Model for the Simple Network Management Protocol (SNMP)",
>             July 2011.
>
> spt
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>