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

Sriganesh Kini <sriganesh.kini@ericsson.com> Mon, 04 October 2010 18:07 UTC

Return-Path: <sriganesh.kini@ericsson.com>
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 76EF73A6FFC; Mon, 4 Oct 2010 11:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level:
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599]
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 6EQzMKp2xxcO; Mon, 4 Oct 2010 11:07:14 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C5FF03A6FF9; Mon, 4 Oct 2010 11:07:13 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o94IMB6X007521; Mon, 4 Oct 2010 13:22:16 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.219]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 4 Oct 2010 14:07:06 -0400
From: Sriganesh Kini <sriganesh.kini@ericsson.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Date: Mon, 4 Oct 2010 14:07:05 -0400
Thread-Topic: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04
Thread-Index: ActjM5K4miiYsgj3RMC+lHpzGTWhyQAuuYUg
Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDEF1A@EUSAACMS0703.eamcs.ericsson.se>
References: <4CA081F7.60304@gondrom.org> <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> <4CA8DDAC.3050801@gondrom.org>
In-Reply-To: <4CA8DDAC.3050801@gondrom.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 04 Oct 2010 11:36:00 -0700
Cc: "swallow@cisco.com" <swallow@cisco.com>, Wenhu Lu <wenhu.lu@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org" <draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org>, "martin.vigoureux@alcatel-lucent.com" <martin.vigoureux@alcatel-lucent.com>, "iesg@ietf.org" <iesg@ietf.org>, "adrian.farrel@huawei.com" <adrian.farrel@huawei.com>, "loa@pi.nu" <loa@pi.nu>
Subject: Re: [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, 04 Oct 2010 18:07:15 -0000

Explanation inline @ [Sri]

Thanks

- Sri
 

> -----Original Message-----
> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] 
> Sent: Sunday, October 03, 2010 12:47 PM
> To: Sriganesh Kini
> Cc: iesg@ietf.org; secdir@ietf.org; 
> draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org; Wenhu 
> Lu; swallow@cisco.com; loa@pi.nu; adrian.farrel@huawei.com; 
> martin.vigoureux@alcatel-lucent.com
> Subject: Re: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04
> 
> 
>  Answers inline [tg]
> BR, Tobias
> 
> On 10/01/2010 09:08 PM, Sriganesh Kini wrote:
> > Hello Tobias,
> >
> > Pls see inline at [Sri].
> >
> > Thanks
> >
> >> -----Original Message-----
> >> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]
> >> Sent: Monday, September 27, 2010 4:37 AM
> >> To: iesg@ietf.org; secdir@ietf.org
> >> Cc: draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org;
> >> Sriganesh Kini; Wenhu Lu; swallow@cisco.com; loa@pi.nu; 
> >> adrian.farrel@huawei.com; martin.vigoureux@alcatel-lucent.com
> >> Subject: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04
> >>
> >>
> >>  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?
> > [Sri] Since the link is only delayed from being added to 
> the LSDB we don't believe there are any new/additional 
> security implications.
> [tg] still the delay is in theory not time limited, but based 
> on the condition of LDP of the link. In combination with #2 
> (below) that the cut-edge of the network may actually be 
> calculated falsely, can this be exploited or lead to unreachability?
> Note: although your remark is right regarding similarities 
> with 5443, the criteria in 5443 is much weaker as it only 
> increases its metric, but does not remove it from LSDB/hold 
> back its entry. Again, I am not an expert on that layer, but 
> I am still uncertain that no security considerations derive 
> from that. Did you consider this scenario when you wrote the 
> draft? Is it unrealistic that it could be exploited with bad 
> intentions?
> If not, which would be the underlying implied pre-conditions 
> to be met to avoid such or under which pre-conditions could 
> such a problem occur?
> (potential input for the security considerations section)

[Sri] The weaker criteria of RFC 5443 does not ensure that the problem does not exist there. In fact the problem exists in a plain IP network with link-state IGP. If the directly connected path has a higher metric than an alternate path with TTL (say > 255) hops then the standard SPF will conclude that the shortest path is the alternate path although through this path the neighboring node is unreachable. Note that in this case the link is advertised with its normal metric yet there is unreachability in the network.

>  
> >> 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)?
> > [Sri] This problem is not unique to this draft. Even in RFC 
> 5443 when the link has high metric, an alternate path with 
> num hops > 255 (but a lower path metric than the directly 
> connected link's max metric) can result in unreachability.
> >
> >> 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
> > [Sri] Accepted
> >
> >> - Appendix A: Computation of 'cut-edge'
> >> there should be an informative reference for mentioned "Dijkstra's 
> >> algorithm"
> > [Sri] Accepted. Will refer to RFC 2328 sec 16.1
> >
> >> - abbreviation "SPF" should list the its expanded term 
> (Shortest Path
> >> First) at first mentioning.
> > [Sri] Accepted.
> >
> >> Best regards, Tobias
> >>
> >>
> >>
> >>
> >>
> 
>