[Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations

<bruno.decraene@orange.com> Tue, 18 November 2014 16:54 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94951A1AA9 for <idr@ietfa.amsl.com>; Tue, 18 Nov 2014 08:54:41 -0800 (PST)
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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7ef0kbNjnBa for <idr@ietfa.amsl.com>; Tue, 18 Nov 2014 08:54:40 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8398F1A1A98 for <idr@ietf.org>; Tue, 18 Nov 2014 08:54:34 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 828B132468E for <idr@ietf.org>; Tue, 18 Nov 2014 17:54:32 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6C6F435C08D for <idr@ietf.org>; Tue, 18 Nov 2014 17:54:32 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 18 Nov 2014 17:54:32 +0100
From: bruno.decraene@orange.com
To: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations
Thread-Index: AdACMQEoWvGvHC+xQV69IWWhZ7m00w==
Date: Tue, 18 Nov 2014 16:54:32 +0000
Message-ID: <8569_1416329672_546B79C8_8569_2021_1_53C29892C857584299CBF5D05346208A07265A06@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.5.145424
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SlNLGW2uwSVqdYY3khlFT12r-BM
Subject: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Tue, 18 Nov 2014 16:54:42 -0000

Hi authors,

Some routes may be received unlabeled (from untrusted sources) and redistributed as labeled. e.g. IPv6 → 6PE, IP --> VPN IP
How would the AS protect itself (from SID collision) from non labeled/trusted  routes received with a SID attributes, and then re-advertised as labelled?

"   A BGP speaker receiving a BGP Label index attribute from its EBGP
   neighbor SHOULD discard the attribute unless it is configured to
   accept the attribute from the EBGP neighbor."

Is good but may not be sufficient as the above BGP speaker (ASBR) may not support this document and hence will propagate the attribute over iBGP sessions. (unless we require that all routers support this document in which case we may not need a transitive attribute, which would by itself address the problem)

One option would be to mandate that by default a BGP session/peer group/AFI remove the received SID attribute. (or at least do not honor it, but I don't see the use case to keep the attribute that we don't want to use)
 e.g. something like "To contain distribution of the BGP
   Label Index attribute beyond its intended scope of applicability,
   attribute filtering MAY be deployed."

But for _received_ routes and with :s/MAY/SHOULD.

At least the currently empty security consideration section should probably discuss this.

Thanks,
Regards.
Bruno

PS: On a side note "Segment Routing Architecture" should probably be a normative reference.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.