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

Dan Frost <danfrost@cisco.com> Thu, 16 June 2011 09:47 UTC

Return-Path: <danfrost@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7508511E8102 for <secdir@ietfa.amsl.com>; Thu, 16 Jun 2011 02:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm9RKDIbWhnu for <secdir@ietfa.amsl.com>; Thu, 16 Jun 2011 02:47:01 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CAAEB11E80F4 for <secdir@ietf.org>; Thu, 16 Jun 2011 02:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; 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 rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2011 09:46:40 +0000
Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5G9keFl030974; Thu, 16 Jun 2011 09:46:40 GMT
Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p5G9kdvr013747; Thu, 16 Jun 2011 05:46:39 -0400
Received: (from danfrost@localhost) by isolaria.cisco.com (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 <danfrost@cisco.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20110616094639.GB12211@cisco.com>
References: <p06240800ca1af8a1d167@[128.89.89.178]> <20110613101524.GA26345@cisco.com> <p06240804ca1d48c85926@[128.89.89.178]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240804ca1d48c85926@[128.89.89.178]>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Thu, 16 Jun 2011 03:48:03 -0700
Cc: swallow@cisco.com, loa@pi.nu, rcallon@juniper.net, stbryant@cisco.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-mpls-loss-delay-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: 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!

-d

> Steve