Hello, 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. IMHO, the document is  Ready with issues . I have t wo main comments: 1- This document has an interesting security considerations section. However it lacks some key information. First of all, there is no attacker model. Is the threat coming from corrupted equipment? Do we assume those attackers have full control over the equipment and flows? Are attackers on path or off path? Clarifying these points (it's not an exhaustive list) would help structuring the discussion on a case by case basis. 2- Something else to clarify: I have the feeling (after quickly searching integrity/ authentication/HMAC/... keywords in the doc) that is no message integrity nor sender authentication mechanism in the echo request/response detailed here. If the attacker model also includes a full control of LSR, nothing can be done to prevent some attacks. Please clarify. And a few additional ones: 3- First sentence says:    "Overall, the security needs for LSP ping are similar to those of ICMP ping." Such debugging tools as ping and traceroute (not speaking of MPLS version here) have an efficiency that heavily relies on (sometimes arbitrary) decisions made by the system administrators whose security policies lead to total or partial blackholes. Hence my questions: is the situation similar with MPLS or can we expect more homogeneous and favorable security policies (e.g., because there's a limited number of administrative domains, or because we are not relying on an ICMP mechanism any more, or because the present document is more directive on what a system administrator should authorize/block/limit)? This could change a lot the security aspects and the potential impacts on the debugging tools. 4- Later it is said:      "To avoid potential Denial-of-Service attacks, it is RECOMMENDED that      implementations regulate the LSP ping traffic going to the control      plane.  A rate limiter SHOULD be applied to the well-known UDP port      defined below." - Do you mean port 3503? It is mentionned but not defined below in this section.   Wording should be adjusted. - It is not clear to me by reading this sentence if it concerns the sender   (who sends traffic to the control plane) or forwarding nodes, which I guess   are the target. In other words, "going to the control plane" is somewhat   ambiguous. 5- Then:      "To protect against unauthorized sources using MPLS echo request      messages to obtain network information, it is RECOMMENDED that      implementations provide a means of checking the source addresses of      MPLS echo request messages against an access list before accepting      the message." Are ACL efficient in this context? If an attacker can forge the source address, it's not. Unless some cryptographic mechanism is used, there's little hope to provide a secure ping service. This is a follow up of comment 1. - Typo:      "...an implementation MAY also validate the TimeStamp      Sent by requiring an exact match on this field." Sent => sent. Cheers,   Vincent Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail