[secdir] secdir review of draft-ietf-pals-p2mp-pw-lsp-ping-03.txt
Sandra Murphy <sandy@tislabs.com> Thu, 22 June 2017 17:48 UTC
Return-Path: <sandy@tislabs.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 BABD1128BB7; Thu, 22 Jun 2017 10:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7gIlcOzcnsQP; Thu, 22 Jun 2017 10:48:42 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA491252BA; Thu, 22 Jun 2017 10:48:41 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3711728B003B; Thu, 22 Jun 2017 13:48:41 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D3F1B1F8036; Thu, 22 Jun 2017 13:48:40 -0400 (EDT)
From: Sandra Murphy <sandy@tislabs.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Jun 2017 13:48:38 -0400
Message-Id: <D32007C6-61C0-457F-9B46-E403795B29AD@tislabs.com>
To: IETF Security Directorate <secdir@ietf.org>, draft-ietf-pals-p2mp-pw-lsp-ping@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LGCj9S5G4CPB_YJZ5iL2mun4teg>
Subject: [secdir] secdir review of draft-ietf-pals-p2mp-pw-lsp-ping-03.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 22 Jun 2017 17:48:44 -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 summary of the review is No Concerns except Nits for the draft. This draft introduces a new sub-TLD to LSP-PIMG for P2MP, for the purpose of monitoring P2PM PW. Note: there is quite a deep stack of RFCs on which this draft is based. I read a lot of them but not all and I can't claim that I now understand how this all works. Take that into consideration in my comments. --Sandy Nits: There are many use or non-use of "a" and "the", leaving the reader confused as to whether one or many of the objects are being discussed. There are related mismatches of subject and verb. A few examples: P2MP PWs are carried over P2MP MPLS LSP - PWs over a LSP? over LSPs in general? One PW over multiple LSPs? The P2MP MPLS LSP are - LSP is or LSPs are receiver at P2MP MPLS LSP tail - at a tail? at the tails? and so forth. There is a terminology section that covers basic concepts like ATM and LSR, but not acronyms used here like ACH, T-PW, AC, GAL, etc are not mentioned. I could not find the term P-tree in the references. Web searches found one vendor's literature and presentations that use that term. If it is vendor specific, it should be changed. section 5 says: The LSP Ping Echo request IPv4/UDP packets is encapsulated with the MPLS label stack as described in previous sections, followed by one of the two encapsulation options: Section 6 says For an Aggregate Inclusive P-tree arrangement, the echo request packet is sent over the P2MP MPLS LSP with one of the following two encapsulation options: I could not resolve the two encapsulation options, whether these were two cases each with its own pair of choices, or one encapsulation encapsulated in the other. It could be made clearer. The security consideration section says it introduces no new "security considerations" beyond those that apply to RFC6425. It is true it introduces no new vulnerabilities, but it does introduce a new set of objects (P2MP PWs) that could be affected by any security issues in RFC6425. RFC6425 introduces the TLVs and sub-TLVs to LSP PING for the purpose of monitoring P2MP LSPs. Its security considerations section says it does not introduce "security concerns" beyond those described in RFC4379. It is probably true it introduces no new vulnerabilities, but it does introduce a new set of objects (P2MP LSPs) that could be affected by any security issues in RFC4379. RFC4379 (LSP Ping) security considerations section covers several points about the security of LSP Ping. The following is a concern over an apparent lack of concern in the stack of RFCs on which this draft is based - for which this draft is not responsible. I can hardly blame this draft for some issue I have in the deep stack of RFCs on which it builds. RFC4379 says in part that Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring and exact match on this field. It is not clear to me that this includes consideration of actions by a legitimate LSP Ping participant. A legitimate LSP Ping participant is in a position in an AS to easily produce spoofed echo requests or to spoof replies to a echo request because it sees the echo requests to which it replies. Consequences of spoofing a request or, particularly, a reply (or in P2PM LSP, a bunch of replies) are not mentioned. Operators I've asked usually say that MPSL is not generally used between ASs. However, inter-AS use of LSP-Ping is mentioned in many of the tree of RFCs on which this draft is built - 4379 and 7117, also found in 8029, 6074, 6514, 7582, 7899, 7900... And many web searches find vendor documentation and operator tutorial sites about the use of inter-AS LSPs - there appear to be three options, one of which is to let the signalling protocols pass between the ASs. I don't know how widely that would be useful (the responses of the operators I've spoken to seem to indicate it is not widely used). But the consequences of a legitimate but misbehaving LSP Ping speaker in one AS affecting the ops and management of another ought to be mentioned somewhere, somehow, at least as a cautionary "don't shoot yourself"
- [secdir] secdir review of draft-ietf-pals-p2mp-pw… Sandra Murphy