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

Stephen Kent <> Tue, 14 June 2011 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4AA921F8503 for <>; Tue, 14 Jun 2011 11:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nOWe3p4+vngD for <>; Tue, 14 Jun 2011 11:07:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 22C6621F84F9 for <>; Tue, 14 Jun 2011 11:07:33 -0700 (PDT)
Received: from ([]:49225) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1QWY1U-0009Ll-4k; Tue, 14 Jun 2011 14:07:32 -0400
Mime-Version: 1.0
Message-Id: <p06240804ca1d48c85926@[]>
In-Reply-To: <>
References: <p06240800ca1af8a1d167@[]> <>
Date: Tue, 14 Jun 2011 13:47:05 -0400
To: Dan Frost <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: Tue, 14 Jun 2011 18:07:33 -0000

At 11:15 AM +0100 6/13/11, Dan Frost wrote:
>Hi Stephen,
>Thanks for your review!  However, it looks like you reviewed an
>out-of-date version of draft-ietf-mpls-loss-delay.  The current version
>is -03 and this version includes a rewrite of the security
>considerations.  (The reference pointers between the two drafts often
>don't show the latest versions of the targets so this may have caused
>some confusion.)


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 

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.

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.