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

From: Brian Weis <[email-masked]>
Date: Fri, 1 Jun 2012 11:16:02 -0700

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 1 Jun 2012 14:11:01 -0700

Hi Rajiv,

Your proposed text looks good to me. I think it's good to go with this added.

Thanks,
Brian

On Jun 1, 2012, at 1:37 PM, Rajiv Asati (rajiva) wrote:

> 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: [email-masked]; The IESG
>> Cc: [email-masked]
>> 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
>> 
>> 
>> 
>> 
>> 
> 

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 1 Jun 2012 15:37:35 -0500

Hi Brian,

//

Cheers,
Rajiv

ongoing
off-
connected by a
However
be
multi-hop
recommended as
multi-hop
because
it's
which
defaults.
case: either
open
in an
the

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 1 Jun 2012 16:28:28 -0500

Hi Brian,

Thanks. Will work with my co-author to get the next version submitted.

Cheers,
Rajiv

> Sent: Friday, June 01, 2012 5:11 PM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]; The IESG;
[email-masked]
> Subject: Re: Secdir review of draft-ietf-mpls-ldp-gtsm-07
> 
> Hi Rajiv,
> 
> > 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.
> >> 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.
> >>

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 2 Jun 2012 12:23:37 -0400

Hi Brian,

Many thanks for your review.

The document already talks about these two cases, and also already discusses that multi-hop is out of scope; however I agree with you that highlighting this in the Security Considerations adds to completeness, and also like Rajiv's text.

I just posted a new rev that I believe addresses these (basically Rajiv's text modulo minor edits).

Thanks!

-- Carlos.