[secdir] SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
"Christian Huitema" <huitema@huitema.net> Wed, 29 June 2016 22:57 UTC
Return-Path: <huitema@huitema.net>
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 0235312D8F2 for <secdir@ietfa.amsl.com>; Wed, 29 Jun 2016 15:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjbUMRZV_8uK for <secdir@ietfa.amsl.com>; Wed, 29 Jun 2016 15:57:35 -0700 (PDT)
Received: from xsmtp05.mail2web.com (xsmtp05.mail2web.com [168.144.250.245]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C16A12D8ED for <secdir@ietf.org>; Wed, 29 Jun 2016 15:57:33 -0700 (PDT)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bIOQF-0001PO-9u for secdir@ietf.org; Wed, 29 Jun 2016 18:57:32 -0400
Received: (qmail 19382 invoked from network); 29 Jun 2016 22:57:30 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.174.2]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org>; 29 Jun 2016 22:57:30 -0000
From: Christian Huitema <huitema@huitema.net>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@ietf.org
Date: Wed, 29 Jun 2016 15:57:27 -0700
Message-ID: <029601d1d259$9d2a1c40$d77e54c0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdHSVHw3wGPy2LWlRRa/K3WxEmXT2A==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KVLY2ZrqJUiXLnIZ08H8qP_nI1w>
Subject: [secdir] SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 29 Jun 2016 22:57:37 -0000
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. The document is ready with 2 nits. The document specifies an extension to the Label Distribution Protocol (LDP, RFC 5036) to provide bindings between Pseudo Wires (PW) and Label Switch Paths (LSP) established over MPLS-TP (RFC6773). The goal is to ensure that both directions of the PW are mapped to the same LSP, and thus avoid asymmetric routing. The document specifies additional LDP extensions to carry the required information. The security section acknowledges one concern: that attackers could misuse the option to force a pseudo wire through an unnatural path, either as a denial of service attack, or to facilitate traffic interception. The proposed mitigation to that attack is essentially "careful Implementation", i.e. only accept binding requests where the LSP endpoints match the PW endpoints. Should a mismatch occur, I assume that the endpoint will reject the proposed binding, as specified in section 5, PSN Binding Operation for MS-PW. And here is one nit: I would like to see the verification behavior specified as part of the binding operations, rather than merely mentioned in the security section. Also, is there a specific error case for the security failure, or just the generic error message? The next nit is tied to the general security profile of LDP, which is specified to use TCP(MD5). There is no expectation of privacy for LDP data. I am not sure that the new extensions increase the "privacy surface" of LDP. They do carry global identifiers of source and destination, and inform about the path of packets between these destinations, and it seems that adversaries could use that for monitoring and targeting purposes. But it is possible that the information is already present in LDP. A note to that effect in the security section would have been nice. -- Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-pals-mpl… Mach Chen
- Re: [secdir] SECDIR review of draft-ietf-pals-mpl… Mach Chen
- Re: [secdir] SECDIR review of draft-ietf-pals-mpl… Christian Huitema
- [secdir] SECDIR review of draft-ietf-pals-mpls-tp… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-pals-mpl… Mach Chen
- Re: [secdir] SECDIR review of draft-ietf-pals-mpl… Andrew G. Malis