Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Brian,

Really appreciate your critical review and suggestions. 

I agree to your both of your suggestions, and would propose the
following text for us to include in the next revision.


//
As discussed in section 3, it is possible that 
- GTSM for LDP may not always be enforced on a single-hop LDP peering
session and may still be susceptible to forged/spoofed protocol packets,
if the single-hop LDP peering session is set up using Extended
Discovery. 
- GTSM for LDP may cause LDP peering session to not get established (or
torn down), if IP routing ever declares that the directly connected peer
is more than one hop away.
Suffice to say, use of cryptographic integrity (e.g., RFC 5925) is
recommended as an alternate solution for detecting forged protocol
packets (especially for the multi-hop case).
//

Cheers,
Rajiv


> -----Original Message-----
> From: Brian Weis (bew)
> Sent: Friday, June 01, 2012 2:16 PM
> To: [e-mail]; The IESG
> Cc: [e-mail]
> Subject: Secdir review of draft-ietf-mpls-ldp-gtsm-07
> 
> 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
> 
> 
> 
> 
>