[secdir] Secdir review of draft-ietf-mpls-pim-sm-over-mldp-02

Tero Kivinen <kivinen@iki.fi> Fri, 24 October 2014 12:59 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 703521A0012; Fri, 24 Oct 2014 05:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5AinkX9gO4XN; Fri, 24 Oct 2014 05:59:45 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BB91A0011; Fri, 24 Oct 2014 05:59:45 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s9OCxdAd028847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Oct 2014 15:59:39 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s9OCxdQq000670; Fri, 24 Oct 2014 15:59:39 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21578.19770.770265.746966@fireball.kivinen.iki.fi>
Date: Fri, 24 Oct 2014 15:59:38 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-pim-sm-over-mldp.all@tools.ietf.org
X-Edit-Time: 6 min
X-Total-Time: 6 min
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/I1IgAMIYzYdep-d2KEOH1zRJkYc
Subject: [secdir] Secdir review of draft-ietf-mpls-pim-sm-over-mldp-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: <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: Fri, 24 Oct 2014 12:59:47 -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 describes how to map IP multicast trees to the
point-to-multipoint label switched paths. This document uses lots of
protocols that I have no idea about, so I have no idea whether there
are real problems or not.

The security considerations section consist of this text:

5. Security Considerations

   All the security considerations for mLDP ([RFC6388]) apply here.

The security considerations section of RFC6388 point to the security
considerations of the RFC5036 and states:

   The protocol specified in this document does not provide any
   authorization mechanism for controlling the set of LSRs that may join
   a given MP LSP.  If such authorization is desirable, additional
   mechanisms, outside the scope of this document, are needed.  Note
   that authorization policies cannot be implemented and/or configured
   solely at the root node of the LSP, because the root node does not
   learn the identities of all the leaf nodes.

Which would indicate that there is no way to secure the Transit
IPv{4,6} Shared Tree TLVs defined in this draft. Those TLVs specify
Rendezvous Point for the multicast group. I have no idea whether some
kind of attacks can be done if unauthorized peer sends such messages
and for example tries to do some kind of denial of service attack
against someone else by forwarding lots of multicast trafic to peer
who does not want it. Or I might be completely misunderstood what is
going on here...