Re: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03
Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Wed, 18 November 2009 12:11 UTC
Return-Path: <Martin.Vigoureux@alcatel-lucent.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB8D3A6B72 for <secdir@core3.amsl.com>; Wed, 18 Nov 2009 04:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.249
X-Spam-Level:
X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJang9eDPwu3 for <secdir@core3.amsl.com>; Wed, 18 Nov 2009 04:11:13 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 736443A6948 for <secdir@ietf.org>; Wed, 18 Nov 2009 04:11:12 -0800 (PST)
Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAICB2TF002365; Wed, 18 Nov 2009 13:11:02 +0100
Received: from [172.27.205.212] ([172.27.205.212]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:11:02 +0100
Message-ID: <4B03E456.7040900@alcatel-lucent.com>
Date: Wed, 18 Nov 2009 13:11:02 +0100
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <a123a5d60910061942h8f0504cjf7e1c3525c364d4d@mail.gmail.com>
In-Reply-To: <a123a5d60910061942h8f0504cjf7e1c3525c364d4d@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 18 Nov 2009 12:11:02.0113 (UTC) FILETIME=[321C4D10:01CA6848]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80
X-Mailman-Approved-At: Wed, 18 Nov 2009 08:10:24 -0800
Cc: dward@cisco.com, malcolm.betts@huawei.com, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2009 12:11:14 -0000
Dear Phillip, thanks for your review. Would the following rephrasing (of the Security Considerations) satisfy your expectations? For your information, Tim Polk had a similar type of comment as part of IESG Review and is ok with the text proposed below. Thanks martin OLD In general, mechanisms SHOULD be provided to ensure that OAM functions cannot be accessed unauthorized. Further, OAM messages MAY be authenticated to prove their origin and to make sure that they are destined for the receiving node. An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. NEW OAM systems (network management stations) SHOULD be designed such that OAM functions cannot be accessed without authorization. OAM protocol solutions MUST include the facility for OAM messages to authenticated to prove their origin and to make sure that they are destined for the receiving node. The use of such facilities MUST be configurable. An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. Phillip Hallam-Baker a écrit : > I am reviewing this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Feel free to > forward to any appropriate forum. > > > This documents sets out requirements for Operations, Administration > and Maintenance of MPLS Transport Profile. > > It is a high level architectural requirements document, intentionally > separated from the details of specific implementations. As such it is > appropriate for the security considerations section to be at a high > level. > > It is however a mystery to this reader why encryption is specified as > a should but integrity protections only merit a MAY. I would be much > more reassured by a document that ignores confidentiality issues > completely (as has been the general policy for low level routing &ct.) > and points out the fact that this is yet another opportunity for a > malicious party to play merry heck by introducing bogus data that > other parts of the network will then operate on. > > For example, introduction of bogus messages would allow an attacker to > reserve excessive bandwidth in the name of another party, possibly > performing a DoS attack or possibly to perform a financial fraud, > causing some party to incur costs for bandwidth not required. > > In comparison the confidentiality issues are rather minor, and in any > event almost certainly subsumed by the fact that anyone who can > observe the content of the OAM packets can almost certainly observe > the volumes of the data flows and infer that information. While > confidentiality is a nice to have, it is not worth much without > integrity. > > I suggest that the security considerations section makes the ability > to support integrity protections a MUST or SHOULD requirement. If only > a SHOULD is applied, confidentiality would be better demoted to MAY. >
- [secdir] SECDIR review of draft-ietf-mpls-tp-oam-… Phillip Hallam-Baker
- Re: [secdir] SECDIR review of draft-ietf-mpls-tp-… Martin Vigoureux
- Re: [secdir] SECDIR review of draft-ietf-mpls-tp-… Phillip Hallam-Baker