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

David Allan I <> Tue, 14 December 2010 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C93BA28C0DC; Tue, 14 Dec 2010 09:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtvFKla8sfuj; Tue, 14 Dec 2010 09:05:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 22C6628C0DB; Tue, 14 Dec 2010 09:05:06 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id oBEH6cMt011713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Dec 2010 11:06:44 -0600
Received: from ([]) by ([]) with mapi; Tue, 14 Dec 2010 12:06:40 -0500
From: David Allan I <>
To: Vincent Roca <>, "" <>, "" <>
Date: Tue, 14 Dec 2010 12:06:39 -0500
Thread-Topic: SecDir review of draft-ietf-mpls-tp-oam-framework-09
Thread-Index: Acubf7u2LtRaZBydSAGC5u99SpErPAAL3XbQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800
Cc: "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-mpls-tp-oam-framework-09
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Dec 2010 17:05:07 -0000

HI Vincent:

Thank you for the detailed read of the section and your comments....

There are a couple of problems associated with the volume of SAs required  that IMO there is no obvious way to mitigate...

The primary example that comes to mind is fault management...

1) Heartbeats are running between LSP endpoints at a an interval as low as 3.3msec interval. The number of SAs is bounded but applying some form of crypto per-packet authentication would just about melt any existing implementation. This discussion has already come up independently in the BFD WG w.r.t. the authentication option.

2) Applying authentication to the generation of notification messages from intermediate nodes in the path means the number of SAs goes up in direct proprotion to the number of hops in the path length of each LSP if the SAs are to be established prior to actually being required in the interest of timely generation of notifications. Negotiating the establishment of each SA on the fly would appear to add significant delays in what is supposed to be an instantaneous network response so does not appear to be a practical option for reducing the scaling impact of maintaining a full set of SAs for all eventualities...

Now we probably overstate the case for crypto in the section (reference to password exchange) and will edit accordingly. What we are exchanging is state about the operational status of a given entity with a minimum of authentication/non-repudiation exclusively on internal links to a network. If a malicious party is able to tap into one of those links they would be able to insert or modify transactions./messages as to mask the true state of the network. 

SO on the basis of the above any suggestions as to how the section can be improved would be welcome. BTW thanks for pointing out that man in the middle has a more specific context that our usage, we will edit accordingly.


-----Original Message-----
From: Vincent Roca [] 
Sent: Tuesday, December 14, 2010 3:11 AM
Subject: SecDir review of draft-ietf-mpls-tp-oam-framework-09

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

I hope these comments are useful.