Skip to main content

Last Call Review of draft-ietf-mpls-ldp-gtsm-
review-ietf-mpls-ldp-gtsm-secdir-lc-weis-2012-06-19-00

Request Review of draft-ietf-mpls-ldp-gtsm
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-05-29
Requested 2012-05-18
Authors Carlos Pignataro , Rajiv Asati
I-D last updated 2012-06-19
Completed reviews Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-mpls-ldp-gtsm by Security Area Directorate Assigned
Result Ready
Completed 2012-06-19
review-ietf-mpls-ldp-gtsm-secdir-lc-weis-2012-06-19-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 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