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"