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

Brian Weis <bew@cisco.com> Fri, 01 June 2012 18:16 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 74BCE21F897C; Fri, 1 Jun 2012 11:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.3
X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8QddUgIOAe0k; Fri, 1 Jun 2012 11:16:04 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id D49E221F8979; Fri, 1 Jun 2012 11:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1882; q=dns/txt; s=iport; t=1338574564; x=1339784164; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=oWsTGyDlvj1VaMR/gxzDgMjl0DRcqPjWbmB7+R4YImM=; b=hRDzHWAiXL9z+l86bGdZg8BcDKhhRuOsLidMQdhVePmu593Yf8cmkzH9 JoFwKY2CBc/TY+eWT8L6IB9maGLygoGK/c4BFf9HO6AuudPC3eQ71d7M0 IbGT/eE/Oav2o1rPfx0RBeXtqfRy4Fzrji8Qz6oLGJXPFkz0ZSbW6l8xu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEABAGyU+rRDoI/2dsb2JhbABFtD+BB4IxASc/gT4BLQeHaJgkn2WQJGADiECMWY4PgWaDAA
X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="44196675"
Received: from mtv-core-3.cisco.com ([]) by mtv-iport-1.cisco.com with ESMTP; 01 Jun 2012 18:16:03 +0000
Received: from sjc-vpn6-2027.cisco.com (sjc-vpn6-2027.cisco.com []) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q51IG2KI029112; Fri, 1 Jun 2012 18:16:02 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jun 2012 11:16:02 -0700
Message-Id: <714A20F7-D17E-46A9-9145-1BB07BED3326@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Cc: draft-ietf-mpls-ldp-gtsm.all@tools.ietf.org
Subject: [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 18:16:05 -0000

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.