[secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 27 September 2010 11:40 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCAB3A6CED for <secdir@core3.amsl.com>; Mon, 27 Sep 2010 04:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.918
X-Spam-Level:
X-Spam-Status: No, score=-94.918 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC0v7d8awemv for <secdir@core3.amsl.com>; Mon, 27 Sep 2010 04:40:43 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id CF98C3A6C99 for <secdir@ietf.org>; Mon, 27 Sep 2010 04:39:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Qog6Z0TvqqBW7qC5rQzHAEeYIEpDZyyIWSUwzhJRdWyZuycGZN6pefrrEUx8gn9fmJd7GylKOVcIy8GrfZ3q9roayrqRkpsqMscSmHrZGGqjBO1bNWtVvw37XOuJ3gUp; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 20026 invoked from network); 27 Sep 2010 13:36:34 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Sep 2010 13:36:34 +0200
Message-ID: <4CA081F7.60304@gondrom.org>
Date: Mon, 27 Sep 2010 12:37:27 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: swallow@cisco.com, wenhu.lu@ericsson.com, draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org, adrian.farrel@huawei.com, sriganesh.kini@ericsson.com, martin.vigoureux@alcatel-lucent.com, loa@pi.nu
Subject: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 27 Sep 2010 11:40:47 -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.


draft-ietf-mpls-ldp-igp-sync-bcast-04 
LDP IGP Synchronization for broadcast networks

the draft updates RFC 5443 (LDP IGP Synchronization)
It basically proposes the following mechanism: "If an interface is not a
'cut-edge' then the updating of the LSA with that link to the
pseudo-node is postponed until LDP is operational."

The document states that there would be no security considerations
beyond RFC5443.
I am not certain of that. Although the idea behind bcast is good, it
adds a new mechanism beyond 5443.
To make sure the security considerations are accurate, I'd like to raise
two questions for the authors/WG:
1. Which security implications does the WG see for removing a coming up
link from the LSDB?
2. Can there be a gap between the algorithm to determine "cut-edge" and
TTL (e.g. may not qualify for "cut-edge" and thus be removed from LSDB,
but have a large number of links and effectively not be reachable)?

and three minor editorial comments:
- section 3, last paragraph:
s/Since A's cost to reach B not high/Since A's cost to reach B is not high
- Appendix A: Computation of 'cut-edge'
there should be an informative reference for mentioned "Dijkstra's
algorithm"
- abbreviation "SPF" should list the its expanded term (Shortest Path
First) at first mentioning.

Best regards, Tobias