Re: [secdir] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15

Gregory Mirsky <> Thu, 19 November 2015 17:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1BF341B2DAC; Thu, 19 Nov 2015 09:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K3KrJVl4QGj5; Thu, 19 Nov 2015 09:17:50 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBDD21B2D99; Thu, 19 Nov 2015 09:17:49 -0800 (PST)
X-AuditID: c6180641-f792c6d00000686a-62-564d9605d567
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BF.67.26730.5069D465; Thu, 19 Nov 2015 10:27:34 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 12:17:48 -0500
From: Gregory Mirsky <>
To: "Osterweil, Eric" <>, "" <>, "" <>, "" <>
Thread-Topic: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15
Thread-Index: AQHRIuYw7V87NEQ2wUqsDEPnZR2Utp6jkbrw
Date: Thu, 19 Nov 2015 17:17:47 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF112219442ECeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPuC7bNN8wg2/zOCwe//3HarHuwmUm ixl/JjJbfFj4kMWBxWPJkp9MHl8uf2bz2LW5gS2AOYrLJiU1J7MstUjfLoErY8u1nywFB30r Vm/8xtzAuMSpi5GTQ0LAROLp1omsELaYxIV769lAbCGBI4wSU2aYdTFyAdnLGSUu9m4EK2IT MJJ4sbGHHSQhIvCLUeLf3MlgCWEBS4mLK6YygtgiAlYSHw82QtlGEnO3r2QBsVkEVCW+z7zP 3MXIwcEr4CvR8T8axBQSsJc48KocpIJTwEGicU0b2ERGoHu+n1rDBGIzC4hL3HoynwniTgGJ JXvOM0PYohIvH/+Dul9J4uPv+ewQ9fkShyd3gV3AKyAocXLmE5YJjCKzkIyahaRsFpIyiLiO xILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chwEyMwso5JsDnuYFzwyfIQowAH oxIPb8EknzAh1sSy4srcQ4wSHMxKIry/nvmGCfGmJFZWpRblxxeV5qQWH2KU5mBREuedN+N+ qJBAemJJanZqakFqEUyWiYNTqoExaO4iM6e5t5xnrkqYc0dEoTd923uzoKQjm/lWqvcf7F5o opXfOid4/Z9mBv/XnXOfzqqY+zusakros27b6l8Z9UKzJsX07tKRnj955iL+bO47Ky/k/bm9 NPBcwPc1YYXSV0+7GGnUVXTL/9h13szrjubMbxO7BPSY9nWGLXC8yFyvfXD2tdpkJZbijERD Leai4kQASei71qgCAAA=
Archived-At: <>
X-Mailman-Approved-At: Thu, 19 Nov 2015 09:20:26 -0800
Subject: Re: [secdir] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 17:17:53 -0000

Hi Eric,

thank you for the review and the comments. Please find my answers in-line and tagged GIM>>.

Your questions, suggestions are greatly appreciated.



-----Original Message-----
From: Osterweil, Eric []
Sent: Thursday, November 19, 2015 8:20 AM
Subject: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15

I have 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.

I believe this draft is ready with (possibly minor) issues:

In Section 2.1.1, the authors describe BFD Authentication, and it seems quite appropriate and well described.  I was, however, wondering if authentication (the same sub-TLV or different) was needed or should be used for the mechanisms in Sections 2.1.2 and 2.1.3.  If the authentication described by 2.1.1 is already expected to be applicable to these other TLVs, it was not immediately clear.  Maybe some additional description of this would be helpful to readers.

GIM>> MPLS-TP Performance Measurement being defined in RFC 6375 is the profile of RFC 6374 and, as we can find across MPLS OAM, does not use any authentication mechanism. Authentication mechanisms been defined for BFD over IP networks and are available when BFD used to monitor MPLS-TP LSP.

In Section 3, there is a great level of granularity proposed around describing authorization errors: Auth not supported, Type not supported, and Key mismatch (this is excellent).  One question, is there a missing statement for an outright authentication failure?

GIM>> The document defines configuration of MPLS-TP OAM and thus supports diagnostic of misconfiguration situations. Failure of authentication would be operational state and should be diagnosed and troubleshooted by other instruments then defined in this document.

In Section 6 Security Considerations, it would be nice (if possible) to mention any privacy considerations.  For example, can an unauthorized agents probe capabilities or configurations (such as, authentication or otherwise) of devices?  That is, can someone learn that authentication is being required, and what parameters are needed, etc?  Is all data transmitted in the clear?

GIM>> RFC 4379 does not define any authentication mechanism for MPLS LSP ping and the data are transmitted in the clear. That may be viewed as security concern and perhaps can be discussed as part of work on RFC4379bis<>06>. At the same time, LSP ping doesn't have constructs to allow an agent, authorized or not, to learn of capabilities and/or configuration of the LSR.