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.
>