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 applies the Generalized TTL Security Mechanism (GTSM) mechanism defined in RFC 5082. This mechanism is used by routing protocols as a low-cost non-cryptographic method intended to frustrate off-path attackers. It is applicable when the peer is known to be connected by a single hop. The security considerations of this draft mostly point to RFC 5082's extensive security considerations section, which is appropriate. However because this I-D discusses multi-hop cases in greater detail it would be appropriate for the security considerations section to also discuss multi-hop a bit more. Here are some thoughts for that: 1) Use of cryptographic integrity (e.g., RFC 5925) should be recommended as an alternate solution for detecting forged protocol packets in the multi-hop case. 2) GTSM is expected to be enabled by default for Basic Discovery because it's usually a single-hop, and disabled for Extended Discovery because it's usually multi-hop. But then Section 3 mentions several exceptions, which apparently need to be administratively configured away from the defaults. Failing to do this when needed results in security risks in either case: either GTSM isn't deployed when it should be and the router is inadvertently open to spoofing, or GTSM is deployed when it shouldn't be and this results in an availability issue because LDP packets will be dropped before reaching the LDP peer. This should be stated in the Security Considerations. Brian