[secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03

Phillip Hallam-Baker <hallam@gmail.com> Wed, 07 October 2009 02:41 UTC

Return-Path: <hallam@gmail.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 9BA2828C21F for <secdir@core3.amsl.com>; Tue, 6 Oct 2009 19:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.644
X-Spam-Level:
X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599]
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 1cx-XVEfsmpY for <secdir@core3.amsl.com>; Tue, 6 Oct 2009 19:41:15 -0700 (PDT)
Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id DA28928C1E5 for <secdir@ietf.org>; Tue, 6 Oct 2009 19:41:14 -0700 (PDT)
Received: by ywh15 with SMTP id 15so4245488ywh.5 for <secdir@ietf.org>; Tue, 06 Oct 2009 19:42:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DsMP+EYk2c3+/xgjG7EFW9jZYbCwh6Dh8WvC6QJJOS0=; b=qdRykWsv2FAznIfwH0m6xMocc0GxSfJmUf2/R3fsvnlb6kL+cJBE4c0vRT9eGIENWn EbsA4iVvjplTEROL7K//Ahzgy6L6+DkzqFYLvCk+Y8dLLxdPMy9LCU5S7El4yyec7K4Y gsZIFRewfBPsdPHwEyMMSa3g/4DMQII0oWipI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V5H5Dt9zP6OeFSuut8PWLToYqWa8cVwQ0QLCL7WbwLmUHJal7URzdUk8fME2SDaRPa 10v097YOoJRC/GlazOfvjOITn6sHjqoBDFCI07qmxqGolIFjL4/4A39aObTyKx5P5G/L o2cBHvS/WStscGXtik4ER02ttfARo3VfkbP5g=
MIME-Version: 1.0
Received: by 10.91.74.11 with SMTP id b11mr1150186agl.39.1254883370900; Tue, 06 Oct 2009 19:42:50 -0700 (PDT)
Date: Tue, 06 Oct 2009 22:42:50 -0400
Message-ID: <a123a5d60910061942h8f0504cjf7e1c3525c364d4d@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org, martin.vigoureux@alcatel-lucent.com, dward@cisco.com, malcolm.betts@huawei.com
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [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, 07 Oct 2009 02:41:16 -0000

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.

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/