Re: [secdir] review of draft-ietf-mpls-loss-delay-03

Dan Frost <> Thu, 16 June 2011 09:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7508511E8102 for <>; Thu, 16 Jun 2011 02:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qm9RKDIbWhnu for <>; Thu, 16 Jun 2011 02:47:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CAAEB11E80F4 for <>; Thu, 16 Jun 2011 02:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2507; q=dns/txt; s=iport; t=1308217621; x=1309427221; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+KYs5Wq+nF/EyNakAlzOj18sEk2A0bwpHMmjyTQMRlE=; b=ApWZH7wJETlHrw+yZu8wxReJGJOAo33GzHm+hMl1/DSR1PSHxg1+Wn8n aNBKBU/mAsP3cUtAVKMcJUtqjjKRYnGg7W98ivfU/b/aWJPkn2ZqjlnSh HQAW6AVuzSqJRIlvGZUVy3defcu1F58Ti7ABAakl81XmgFa119pKYrFUE E=;
X-IronPort-AV: E=Sophos;i="4.65,374,1304294400"; d="scan'208";a="377793073"
Received: from ([]) by with ESMTP; 16 Jun 2011 09:46:40 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p5G9keFl030974; Thu, 16 Jun 2011 09:46:40 GMT
Received: from (isolaria []) by (8.13.1/8.13.1) with ESMTP id p5G9kdvr013747; Thu, 16 Jun 2011 05:46:39 -0400
Received: (from danfrost@localhost) by (8.13.1/8.13.1/Submit) id p5G9kdwO013746; Thu, 16 Jun 2011 10:46:39 +0100
Date: Thu, 16 Jun 2011 10:46:39 +0100
From: Dan Frost <>
To: Stephen Kent <>
Message-ID: <>
References: <p06240800ca1af8a1d167@[]> <> <p06240804ca1d48c85926@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240804ca1d48c85926@[]>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Thu, 16 Jun 2011 03:48:03 -0700
Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jun 2011 09:47:02 -0000

Hi Steve,

On Tue, Jun 14, 2011 at 01:47:05PM -0400, Stephen Kent wrote:
> Thanks for pointing me to the most recent version of the base spec. As
> you noted, the profile reference didn't list a version number so ...
> In looking at the new version, I see that the intro text is much
> improved.  It cites use of BFD as an authentication mechanism, and
> refers the reader to 5920, presumably for integrity and authentication
> mechanisms.
> I looked quickly at 5920, and it appears that it does not specify any
> crypto-based mechanisms for a generic pseudowire link (where the
> traffic being carried is not IP). Is that accurate? Also, 5920 cites
> 4447, for LDP-based links, but that RFC seems to cite only TCP-MD5 as
> a crypto-based option, which is now obsoleted by TCP-AO. So It is not
> clear that there are any IETF crypto-based security standards
> available for protecting these messages. I'm not saying that this is a
> show stopper, but rather that this should be more clearly stated
> somewhere.

Yes, that's true; the MPLS data plane is generally implemented and
highly optimized in hardware, so heavyweight security mechanisms like
encryption are left to other layers.  Similarly trying to encrypt these
hardware-assisted loss/delay measurement messages is likely to cause
more problems than it solves; the information they contain is unlikely
to be sensitive enough to justify a complex and costly encryption layer
(which would at best require very specialized hardware support in order
not to interfere with the measurements themselves).

We can add a note about this in the text if that will help.

> Finally, the cite of IPsec in the next text (in the base document)
> provides te sort of concrete, crypto-based security mechanism I had in
> mind when I raised this question. However, I have a question: are the
> loss and delay measurement messages sent via the MPLS G-ACh always
> encapsulated in IP? I could not determine this from looking at the
> base doc, and RFC 5586 seems to indicate that IP is only one option
> for carriage of MPLS OAM packets.

Right, the G-ACh is independent of IP and was designed, among other
things, to meet requirements for MPLS-TP (RFC 5654) that include being
able to function in networks that lack an IP data plane.  The reference
to IPsec in this document pertains to the special case of out-of-band
measurement message responses over IP networks.

Thanks again for the review!


> Steve