[secdir] Secdir review of draft-ietf-pals-mpls-tp-mac-wd-02

Radia Perlman <radiaperlman@gmail.com> Sun, 11 October 2015 06:05 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657F1A86E3; Sat, 10 Oct 2015 23:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 4OVPYG3z40gU; Sat, 10 Oct 2015 23:05:06 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC4E1A86E2; Sat, 10 Oct 2015 23:05:06 -0700 (PDT)
Received: by obcor6 with SMTP id or6so5252503obc.3; Sat, 10 Oct 2015 23:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZMoqaZtxeIIpAtDOJ6KXW9ckHZsUWS/qthVZfqk8kLI=; b=GlftrNwTpgCuM6lZoZb/SMHAnya5OgDliQ+u9ojEGMDf8zD8wMvsmg8efSchXIhipM +UDiG5oscH0V6/8rmFBCVR0LG26wEMGOWPdcGCQLbANtOCu3fGzKZFmxPKbvT5USXG9r qWPP48cwrBQMHp/XmDOIz4SQtBhjezG50B9Idrlz4I2hVfmbSyyvfCObd2pDjRttuKoY apsosvFMs5yWLtwcHLyoRe3K5bpf0HX2SLZSWsrH2nR8doVGoNoDtCSgTNvw1xmUwZU9 bOzX437p/pNP2cexvYj9OPzXOmNqP40gFPTtbSHYgamfSAhGouhOpU5PDLAd7weWh1zw SEvw==
MIME-Version: 1.0
X-Received: by 10.182.29.73 with SMTP id i9mr12501089obh.59.1444543505591; Sat, 10 Oct 2015 23:05:05 -0700 (PDT)
Received: by 10.182.109.33 with HTTP; Sat, 10 Oct 2015 23:05:05 -0700 (PDT)
Date: Sat, 10 Oct 2015 23:05:05 -0700
Message-ID: <CAFOuuo6SV8_FDFV=Y-qf0_cHiqBB-=unvEcqX_28hDTxjpWpaw@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-pals-mpls-tp-mac-wd.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a11c2989e8373f40521cdfe88
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/RfS4z3-P8DMgVPxS-svktxA9iyQ>
Subject: [secdir] Secdir review of draft-ietf-pals-mpls-tp-mac-wd-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 11 Oct 2015 06:05:08 -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.

This document proposes a new subtype to a Pseudo-Wire Operations,
Administration, and Maintenance (PW OAM) Message for the purpose of
withdrawing learned MAC addresses when those addresses cease being
accessible. Label Distribution Protocol (LDP) provides this functionality
for dynamically created pseudo-wires. This RFC defines a mechanism for
doing so in the case of statically provisioned pseudo-wires.

The security considerations section of this document says “The security
measures described in [RFC4447], [RFC5085], and [RFC6073] are adequate for
the proposed mechanism.” That may well be true, but the mechanisms in those
documents are based on address reachability only (rather than cryptographic
mechanisms) and therefore assume a closed network with security enforced by
filtering at access points. Forging messages of this protocol could cause
significant denial of service opportunities for an attacker.

Non-security issues:

On page 5, figure 1, TLV length is an 8 bit field defined as “the total
length of all TLVs in the message”. It does not specify the units, which I
assume come from some other spec. If this is a length in bytes, 255 bytes
seems like an exceptionally small limit for this length.

If I’m reading this correctly, this protocol seems to be a lot less
resilient to lost and reordered packets than it might be. In figure 1, the
use of an ‘R’ bit to reset the sequence numbers seems dangerous if messages
can be delivered out of order. Also, if all copies of a message sent with
the ‘R’ bit are lost, all subsequent messages will also be lost.

On page 6, section 4.1, paragraph 3 says that if additional MACs need to be
withdrawn before a previous withdraw message has been acknowledged,
retransmissions of the old message will cease and the new message will be
transmitted. It does not say whether the new message should combine the
MACs from the old message or not. If not, the probability of the MACs in
the old message being lost is increased. The spec should say one way or the
other.

Nits:

The spec should be reviewed to assure that the words "withdraw" and
"withdrawal" are used consistently. I couldn't discern what the pattern was
supposed to be. On page 2, "withdrawl" should be replaced with one or the
other.

P3: "loss of MAC withdraw signal" -> "loss of a MAC withdraw signal"
P3: "but do not assure" -> "but does not assure"
P4: "plackets" -> "packets"
P7: "acknowledgement is received" -> "acknowledgement is received."  (need
period end of sentence)
P7: "described in [RFC4385]" -> "described in [RFC4385]." (add period end
of sentence)
P7: "Security Consideration" -> "Security Considerations"