Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

"Osborne, Eric" <eric.osborne@level3.com> Wed, 08 June 2016 16:02 UTC

Return-Path: <eric.osborne@level3.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53412D77B; Wed, 8 Jun 2016 09:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2831Q5M49rZT; Wed, 8 Jun 2016 09:02:29 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E1312DA0E; Wed, 8 Jun 2016 09:02:07 -0700 (PDT)
Received: from [216.82.242.131] by server-14.bemta-8.messagelabs.com id CF/22-29672-D7148575; Wed, 08 Jun 2016 16:02:05 +0000
X-Env-Sender: eric.osborne@level3.com
X-Msg-Ref: server-7.tower-76.messagelabs.com!1465401724!53782478!1
X-Originating-IP: [209.245.18.37]
X-StarScan-Received:
X-StarScan-Version: 8.46; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18657 invoked from network); 8 Jun 2016 16:02:05 -0000
Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-7.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jun 2016 16:02:05 -0000
Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 94C611DEBC; Wed, 8 Jun 2016 16:02:04 +0000 (GMT)
Received: from USIDCWVEQCCAS01.corp.global.level3.com (4.72.133.42) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 8 Jun 2016 10:02:04 -0600
Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEQCCAS01.corp.global.level3.com ([::1]) with mapi id 14.03.0279.002; Wed, 8 Jun 2016 10:02:03 -0600
From: "Osborne, Eric" <eric.osborne@level3.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
Thread-Index: AQHRwRJMgil6Oa8w7kqPKG95vvnvsp/fuVJg
Date: Wed, 08 Jun 2016 16:02:03 +0000
Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5@USIDCWVEMBX03.corp.global.level3.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> <BL2PR09MB112327B7295773B20DF5C63F845D0@BL2PR09MB1123.namprd09.prod.outlook.com>
In-Reply-To: <BL2PR09MB112327B7295773B20DF5C63F845D0@BL2PR09MB1123.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.196.207]
Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5USIDCWVEMBX03co_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e65ONW1Fmp-CkJyVxksTU95L75o>
Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" <draft-ietf-idr-route-leak-detection-mitigation@ietf.org>, "'John G. Scudder'" <jgs@bgp.nu>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 08 Jun 2016 16:02:31 -0000

On the basis that detection-mitigation adds an attribute to every route (potentially per AS hop), whereas bgp-open keeps it to the neighbor relationship.  One attribute per route * 600k routes * N hops seems like a lot if I can do the same thing with an open message.  I'm also concerned about how much I should trust the RLP bit from an AS a few hops away.  Getting it from my directly connected neighbor is one thing, but if I can trust the source to do the right thing with the RLP bit, why can't I just assume they won't leak YouTube-ish things to begin with?  It feels a little like "...you SHOULD not rob this bank, but if you're going to rob the bank you MUST NOT wear a mask".  At least with my directly connected neighbor I have some understanding of what the policy should be, and a phone number I can call if things are super-hosed.


I didn't see a discussion of scale anywhere in detection-mitigation.  This seems like such an obvious scale difference to me that I worry that "hard to say that one proposal is more heavy weight than the other in principle" means I'm missing something.  Feel free to enlighten me as needed.



eric


From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sriram@nist.gov]
Sent: Tuesday, June 07, 2016 7:14 PM
To: Osborne, Eric <eric.osborne@level3.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudder' <jgs@bgp.nu>
Subject: RE: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)


Eric,



>4) I just briefly skimmed detection-mitigation, and that seems like a

>much more heavyweight way to implement the same sort of end behavior.



On what basis?

The OTC flag (one for the whole update) in the bgp-open-policy draft

has in essence the same semantics as the RLP flag (one per AS-hop).

In both cases, by setting the flag the sender is indicating that

the route is being sent to a customer or a lateral peer, and hence

SHOULD NOT be sent by the receiving AS or another AS down the path

to its provider or lateral peer.

So hard to say that one proposal is more heavy weight

than the other in principle.



Also, please see the point made in my other post about the inefficacy

of a single OTC flag for the whole update (as proposed in bgp-open-policy):

http://www.ietf.org/mail-archive/web/idr/current/msg15745.html

You may also see a detailed discussion in Section 5.5 of

https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03



Sriram