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

Stephen Kent <kent@bbn.com> Thu, 16 June 2011 13:54 UTC

Return-Path: <kent@bbn.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 AF2A911E8106 for <secdir@ietfa.amsl.com>; Thu, 16 Jun 2011 06:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 6CFDQnvLVv-u for <secdir@ietfa.amsl.com>; Thu, 16 Jun 2011 06:54:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48111E80E3 for <secdir@ietf.org>; Thu, 16 Jun 2011 06:54:00 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47675 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QXD1C-00070d-4a; Thu, 16 Jun 2011 09:53:58 -0400
Mime-Version: 1.0
Message-Id: <p06240801ca1fba5b6bd6@[198.18.54.182]>
In-Reply-To: <20110616094639.GB12211@cisco.com>
References: <p06240800ca1af8a1d167@[128.89.89.178]> <20110613101524.GA26345@cisco.com> <p06240804ca1d48c85926@[128.89.89.178]> <20110616094639.GB12211@cisco.com>
Date: Thu, 16 Jun 2011 09:52:58 -0400
To: Dan Frost <danfrost@cisco.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: swallow@cisco.com, secdir@ietf.org, rcallon@juniper.net, stbryant@cisco.com, loa@pi.nu
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 13:54:00 -0000

At 10:46 AM +0100 6/16/11, Dan Frost wrote:
>Hi Steve,
>...
>
>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).

If you are looking to provide integrity and authentication, then you 
would not be performing encryption, per se, although use of 
cryptographic mechanisms was the question I was asking.

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

If there is a way to use crypto to protect payloads, then saying how 
to do that would be fine. If not, then it should be stated clearly. 
It took a lot of digging to discover that, for the measurement 
messages, there appears to be no crypto option :-).

>
>>  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 for the clarification.

Steve