Last Call Review of draft-ietf-mpls-pim-sm-over-mldp-02
review-ietf-mpls-pim-sm-over-mldp-02-secdir-lc-kivinen-2014-10-30-00

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 iki.fi