Skip to main content

Last Call Review of draft-ietf-mpls-pim-sm-over-mldp-02

Request Review of draft-ietf-mpls-pim-sm-over-mldp
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-11-03
Requested 2014-10-23
Authors Yakov Rekhter , Rahul Aggarwal , Nicolai Leymann , Wim Henderickx , Quintin Zhao , Richard Li
I-D last updated 2014-10-30
Completed reviews Secdir Last Call review of -02 by Tero Kivinen (diff)
Opsdir Last Call review of -02 by Carlos Pignataro (diff)
Rtgdir Early review of -00 by Stig Venaas (diff)
Assignment Reviewer Tero Kivinen
State Completed
Review review-ietf-mpls-pim-sm-over-mldp-02-secdir-lc-kivinen-2014-10-30
Reviewed revision 02 (document currently at 03)
Result Ready
Completed 2014-10-30
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... 
kivinen at