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

Dan Frost <> Mon, 13 June 2011 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D164911E80B0 for <>; Mon, 13 Jun 2011 03:15:30 -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 7bUMr022TA-c for <>; Mon, 13 Jun 2011 03:15:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C091311E808B for <>; Mon, 13 Jun 2011 03:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2836; q=dns/txt; s=iport; t=1307960129; x=1309169729; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=pswqAgheDmIG80h2UL6TJ7Go9Syc0GIvJdw8RRbirbQ=; b=l2e2xzCt72sqE/izsoVpXtnPi05KP2G/cL0HQKzz/iR2wHbrR3IVJDch 1n0rvbeDR0M8U68j0BJV12HHEIoiMMLWXGLwS1IdgD6TRhthPPovjlMJi jZcBv1Yr5TLpzv2sXowuAT5BFUjxaBdFWOxPsA6l3U5Ae54A0aQEKktNp o=;
X-IronPort-AV: E=Sophos;i="4.65,357,1304294400"; d="scan'208";a="236620790"
Received: from ([]) by with ESMTP; 13 Jun 2011 10:15:25 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p5DAFPZR011638; Mon, 13 Jun 2011 10:15:25 GMT
Received: from (isolaria []) by (8.13.1/8.13.1) with ESMTP id p5DAFOtQ026692; Mon, 13 Jun 2011 06:15:24 -0400
Received: (from danfrost@localhost) by (8.13.1/8.13.1/Submit) id p5DAFOqR026691; Mon, 13 Jun 2011 11:15:24 +0100
Date: Mon, 13 Jun 2011 11:15:24 +0100
From: Dan Frost <>
To: Stephen Kent <>
Message-ID: <>
References: <p06240800ca1af8a1d167@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240800ca1af8a1d167@[]>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Mon, 13 Jun 2011 05:41:38 -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: Mon, 13 Jun 2011 10:15:31 -0000

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.)


On Sun, Jun 12, 2011 at 07:20:22PM -0400, Stephen Kent wrote:
> I 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 abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes
> it as "a profile of the general MPLS loss, delay, and throughput
> measurement techniques that suffices [sic] to meet the specific
> requirements of MLS-TP." It is a very brief (5 pages, including
> boilerplate) document intended as an informational RFC. The document
> that forms the basis for this profile,
> draft-ietf-mpls-loss-delay-01, is also in progress.
> The security considerations section of this document refers to the
> base document cited above. Since this document is a profile of that
> one, this is a reasonable indirection. (I note that the document
> under review cites version 1 of that base document, and that version
> 2 is now current, something that can be addressed later.) I looked
> at the security considerations section of the base specification. It
> is two paragraph in length. The first paragraph does a reasonable
> job of describing the top level security concerns associated with
> the exchange of performance monitoring messages in a context such as
> this. (The text would be better if the third concern were identified
> as "confidentiality.") The second paragraph, however, states:
>    If reception or alteration of performance-related data by
>    unauthorized devices is an operational concern, authentication
>    and/or encryption procedures should be used to ensure message
>    integrity and confidentiality.  Such procedures are outside the
>    scope of this document, but have general applicability to OAM
>    protocols in MPLS networks.
> First, this paragraph is poorly worded (e.g., the mixed uses of
> "authentication," "encryption," "integrity," and "confidentiality").
> Second, there is concrete reference to any candidate security
> mechanisms that can provide such services. I am not aware of any
> IETF standards that might offer such services for MPLS traffic. If
> there are none, this second paragraph is not adequate; if there are,
> they should be cited here.