Re: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-09.txt

"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Wed, 14 May 2008 10:07 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0CD3A682A; Wed, 14 May 2008 03:07:38 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6903A6823 for <idr@core3.amsl.com>; Wed, 14 May 2008 03:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9r57PHZWOWdY for <idr@core3.amsl.com>; Wed, 14 May 2008 03:07:33 -0700 (PDT)
Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id C53903A67A2 for <idr@ietf.org>; Wed, 14 May 2008 03:07:32 -0700 (PDT)
Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JwDIL-0006wL-6x for idr@ietf.org; Wed, 14 May 2008 11:29:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 14 May 2008 11:29:09 +0200
Message-ID: <7000E71D8C525042A815432358B2F1240138D4B2@paul.adoffice.local.de.easynet.net>
In-Reply-To: <20080513174501.449F63A683C@core3.amsl.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-09.txt
Thread-Index: Aci1IZwrxU82p+lfSYmOaQugORilIAAgRLyw
References: <20080513174501.449F63A683C@core3.amsl.com>
From: "Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net>
To: <idr@ietf.org>
Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-09.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On 
> Behalf Of Internet-Drafts@ietf.org
> Sent: Tuesday, May 13, 2008 7:45 PM
> To: i-d-announce@ietf.org
> Cc: idr@ietf.org
> Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-09.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.

I've looked at the draft and in current state there are potentially
problems with sections 2.3 and 4 as follow:

Consider existing iBGP session within AS-A where identifier of the
remote side is X, and then new session connection comes from AS-B but
also having BGP identifier of X. If AS-B is numerically larger than
AS-A, then according to section 2.3 of the draft iBGP session towards
router with id X should be closed. This is security issue - an attacker
with high AS number could deliberately set router-id to be same as some
other router of a peering network (they may or may not be penalised for
this but perhaps they want to do it anyway), effectively causing
shutdown of iBGP session in remote AS. Nevertheless, section 4 of the
draft says that security issues are not changed by the draft - I believe
they're, and they make protocol weaker than original spec.

If it's necessary to relax BGP ID definition and have it unique only
locally within given AS, then in all collision detections BGP ID should
only be compared when ASN are equal. If two sessions have same BGP ID on
remote end but each with different ASN, then they should be considered
as different routers.

Kind regards,
iLya
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr