[secdir] SecDir review of draft-ietf-mpls-tp-oam-framework-09

Vincent Roca <vincent.roca@inrialpes.fr> Tue, 14 December 2010 11:09 UTC

Return-Path: <vincent.roca@inrialpes.fr>
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 E80023A6F8C; Tue, 14 Dec 2010 03:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 in9WDU2fvgmn; Tue, 14 Dec 2010 03:09:18 -0800 (PST)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 46D263A6F7F; Tue, 14 Dec 2010 03:09:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.59,341,1288566000"; d="scan'208";a="82585792"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 14 Dec 2010 12:10:57 +0100
Message-ID: <4D0750C1.5090304@inrialpes.fr>
Date: Tue, 14 Dec 2010 12:10:57 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org
Subject: [secdir] SecDir review of draft-ietf-mpls-tp-oam-framework-09
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: Tue, 14 Dec 2010 11:09:20 -0000

Dear all,

I have reviewed 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.

The Security Considerations section of this I-D is fairly strange.
The authors first highlight that OAM traffic contains sensitive
data (like passwords), and then quickly conclude that securing this
traffic is impossible and therefore they require that the network be
physically secured. The reason provided is the fact that there are
too many entities that are likely to communicate to establish and
maintain SAs between them.

Well, I don't know the specificities of MPLS networks, nor the
OAM operations in MPLS networks, however:
1- I need more information to be convinced that there is indeed no
    other solution than requiring that the whole physical network be
    totally secured;
2- I need more information to be convinced that fully securing such
    a physical network is feasible;

Honestly speaking I'm not convinced by 1-. What about solutions
based on temporary SA? Are the OAM exchanges so frequent to require
that each secure connection be maintained all the time? Would a
solution that establishes those connections on-the-fly, when needed,
be realistic? Another direction could be to use shared keys between
the entities of a group. Or perhaps using a per-packet signature
approach is feasible, using some public key infrastructure, if the
exchanges are infrequent. There are probably other IETF protocols
that have similar requirements. What about the KARP WG that focuses
on secure routing protocols? May some ideas be borrowed and applied
here (that's a fully open question)?

Concerning 2-, a quick search on "MPLS attacks" on the web provides
a small number of references. There's also a book on the subject
("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco
Press, 2005). I don't known the domain at all but I'd like to be
convinced that 2- is feasible.


A minor comment.
I have the feeling that the authors use the term "man-in-the-middle
attack" to denote any attack where the attacker takes control of the
physical infrastructure. That's not an appropriate use and this term
refers to a very specific attack (e.g. see
http://en.wikipedia.org/wiki/Man-in-the-middle_attack).

I hope these comments are useful.
Regards,

    Vincent