[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
- [secdir] SecDir review of draft-ietf-mpls-tp-oam-… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-mpls-tp-… David Allan I
- Re: [secdir] SecDir review of draft-ietf-mpls-tp-… Adrian Farrel
- Re: [secdir] SecDir review of draft-ietf-mpls-tp-… Vincent Roca