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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Fri, 01 June 2012 20:37 UTC

Return-Path: <rajiva@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8543611E8097; Fri, 1 Jun 2012 13:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.374
X-Spam-Level:
X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLax1XVuwyAw; Fri, 1 Jun 2012 13:37:37 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF611E808A; Fri, 1 Jun 2012 13:37:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3059; q=dns/txt; s=iport; t=1338583057; x=1339792657; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bHw3hzN2M2U2tmEqIjqS4Oz5X5Q6MFOI5pPe+EPri5E=; b=Q46K3Wq7PHIOx7WJPEjED5Lm7TwaNrr0PS8ldZQtdSzpL1r+olQe0trb DP/zv8fq1NaG/QCT8W8wgWS5HwIPyvlmaLN9Z6vNQuPPKhgEXSJ0mkh4X dvXcw4KfI30W8pLsDXZmbRKKVTprBZ3m7p1U1KtxL7H0QnUKw8tAxxix2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJ4nyU+tJXHB/2dsb2JhbABFtD+BB4IYAQEBBBIBHQo/DAQCAQgRBAEBCwYYBgFOCAEBBAESCBMHh2mYJJ9giw+FFWADiECaaIFmgn4
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="88586209"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jun 2012 20:37:37 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q51KbavQ017984; Fri, 1 Jun 2012 20:37:37 GMT
Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 15:37:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jun 2012 15:37:35 -0500
Message-ID: <B33BBF99CFB5E74D918573915558D90F05168E7A@XMB-RCD-212.cisco.com>
In-Reply-To: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Secdir review of draft-ietf-mpls-ldp-gtsm-07
Thread-Index: Ac1AIqiWSKJ2uH5WSvSwmdbsLclYvwABVedA
References: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "Brian Weis (bew)" <bew@cisco.com>, <secdir@ietf.org>, "The IESG" <iesg@ietf.org>
X-OriginalArrivalTime: 01 Jun 2012 20:37:36.0509 (UTC) FILETIME=[611992D0:01CD4036]
X-Mailman-Approved-At: Fri, 01 Jun 2012 14:37:41 -0700
Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-gtsm-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2012 20:37:38 -0000

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: secdir@ietf.org; The IESG
> Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org
> 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
> 
> 
> 
> 
>