Re: [Idr] Validation for BGP Flow-Spec Redirect to IP Action

"Simpson, Adam 1. (Nokia - CA/Ottawa)" <adam.1.simpson@nokia.com> Sun, 29 April 2018 19:42 UTC

Return-Path: <adam.1.simpson@nokia.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 04523126D45; Sun, 29 Apr 2018 12:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 h8_dAhxp7NM1; Sun, 29 Apr 2018 12:42:31 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576EB126BF6; Sun, 29 Apr 2018 12:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Pn+KIVPFylA5aEFCtJM+Eg96miixn3T4iN+55NZq/z8=; b=e0EnU0AK2g2vQg5ricqqWxFVgZN/26meCg8TYyPHddJATk6Dyv6JAv+pwFmNB9g8U8/e15Naw9LJWoZmu5HtcllUO7hJ+yp30uiel6VuZKHzfnk5aMr+qctbgyLA3yemikWNMFE3lw9ccWyWweIJL7fXfHe3S6Xr2LmaX+UbdFs=
Received: from AM4PR07MB1442.eurprd07.prod.outlook.com (10.165.248.21) by AM4PR07MB1475.eurprd07.prod.outlook.com (10.165.248.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.13; Sun, 29 Apr 2018 19:42:25 +0000
Received: from AM4PR07MB1442.eurprd07.prod.outlook.com ([fe80::b544:585e:d78:3b59]) by AM4PR07MB1442.eurprd07.prod.outlook.com ([fe80::b544:585e:d78:3b59%3]) with mapi id 15.20.0715.014; Sun, 29 Apr 2018 19:42:25 +0000
From: "Simpson, Adam 1. (Nokia - CA/Ottawa)" <adam.1.simpson@nokia.com>
To: PVLR Pavana Murthy <pvlrpm@gmail.com>, "David Smith (djsmith)" <djsmith@cisco.com>
CC: idr wg <idr@ietf.org>, Pradosh Mohapatra <mpradosh@yahoo.com>, "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>, "ju1738@att.com" <ju1738@att.com>, "jhaas@juniper.net" <jhaas@juniper.net>, "akarch@cisco.com" <akarch@cisco.com>, "sairay@cisco.com" <sairay@cisco.com>, "pmohapat@cumulusnetworks.com" <pmohapat@cumulusnetworks.com>, "wim.henderickx@alcatel-lucent.be" <wim.henderickx@alcatel-lucent.be>, "mtexier@arbor.net" <mtexier@arbor.net>
Thread-Topic: Validation for BGP Flow-Spec Redirect to IP Action
Thread-Index: AQHT3qvIvgs0k9FZ1kqdZpgXcrBfhqQX4/2A
Date: Sun, 29 Apr 2018 19:42:24 +0000
Message-ID: <3A1793BA-DB42-49E2-AC8C-FBAD1C433DEA@nokia.com>
References: <CAN-MQG6bDyzcyuVs1vmka-JZFrD9Ya1uOuU_AFxfu0GnYgdmbA@mail.gmail.com> <aaa4916758a34ed99cb7432cff257f25@XCH-RCD-012.cisco.com> <CAN-MQG6R_LCLAM5xgaak3W_oRkuQFQsgZtEodacpeiLCQV8p-g@mail.gmail.com> <CAN-MQG4oyycFhFzWGrKcQUG_B5eatan9y3PJJG1O-2vSLmhttg@mail.gmail.com>
In-Reply-To: <CAN-MQG4oyycFhFzWGrKcQUG_B5eatan9y3PJJG1O-2vSLmhttg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
authentication-results: spf=none (sender IP is ) smtp.mailfrom=adam.1.simpson@nokia.com;
x-originating-ip: [135.245.20.19]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1475; 7:KcANBOmiT8DTZcCBPajLlB6IWpSu893M+P5I9aP+oep+1/PHr7UHHvC5ZZ67BnhL21ZzQSnA4kd+CxE0opVvDK1W8wdfRraPkK5GvLlLpVuTO7C9q9n1qUKiU3DwMD16nRyJtg+9EGQWosBlZAgM1U2IeVQVU6uCvlsfJNaJCEJ9SI/Z7iqa4z7m8Kypod0AG4TC7EQXwlo9SgOMA1ci7rfSy9qiHj4Dw1rp5uQAYCbQtAiHC1M7KyEv/uZ4RVen
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB1475;
x-ms-traffictypediagnostic: AM4PR07MB1475:
x-microsoft-antispam-prvs: <AM4PR07MB14755CE90DE93084A1DB3CD09A830@AM4PR07MB1475.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(131327999870524)(138986009662008)(82608151540597)(85827821059158)(97927398514766)(95692535739014)(240845254718375)(21748063052155)(201166117486090);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR07MB1475; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1475;
x-forefront-prvs: 0657D528EC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(376002)(346002)(366004)(469094003)(57704003)(189003)(51914003)(53484002)(199004)(81166006)(2616005)(66066001)(486006)(14454004)(6512007)(58126008)(83716003)(105586002)(11346002)(86362001)(478600001)(59450400001)(446003)(2906002)(6486002)(82746002)(2900100001)(3660700001)(316002)(476003)(106356001)(54906003)(25786009)(5250100002)(229853002)(4326008)(5660300001)(236005)(110136005)(99286004)(186003)(102836004)(68736007)(39060400002)(33656002)(6246003)(3846002)(6116002)(9326002)(6306002)(53946003)(97736004)(7736002)(36756003)(3280700002)(8666007)(8936002)(6506007)(8676002)(53546011)(26005)(6436002)(81156014)(7416002)(93886005)(76176011)(54896002)(53936002)(390805004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1475; H:AM4PR07MB1442.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RNFzcsA1zSuUmn5f5TY96KEuSbhN5wXG1wmE8tIEHjCxF+pZ+BNMjVTNCJgJQa5wux1dMf9k6+yEHSf2ngw2RanAHMrY4I4M5XtNfGNqYw5SQpjC54O65iQYzjImfiU/I8snxn51KYApsAcbTJZmrrlb4PtxNs2GG63eknGi8cKWoYsZh9vs4ZzVcs4m1TmBKUS+OPArPFf2TpzgFnidJ3qhBrwU4aqOI5i/fMBgAxuNjaO7U0H09OUlQqNLBcL6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3A1793BADB4249E2AC8CFBAD1C433DEAnokiacom_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a4d40258-521b-4282-953a-08d5ae095545
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4d40258-521b-4282-953a-08d5ae095545
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2018 19:42:25.0730 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1475
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cssQtBrkzcIviftUA_yFEtEeM3A>
X-Mailman-Approved-At: Mon, 30 Apr 2018 05:43:07 -0700
Subject: Re: [Idr] Validation for BGP Flow-Spec Redirect to IP Action
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 29 Apr 2018 19:42:35 -0000

Hi Pavana,

The purpose of this text in the draft was to close the door on the ability for an accidental/malicious originator of a flow-spec route in AS=x from redirecting flows towards a target IP address in some other AS=y.

So, in this context we are interested in looking at the first AS in AS_PATH of the flow-spec route, not the most recently added AS in the AS_PATH (which would be the ‘neighbor AS’).

The route that resolves the target redirect IP address could be a BGP route or it could be a non-BGP route, despite the wording in the draft. If it is a BGP route the origin AS is determined as described above. If is a non-BGP route it would probably be appropriate to consider the route as locally originated (i.e. the same as a BGP route with null/empty AS_PATH or having only confed related elements).

I hope this helps.

-Adam


From: PVLR Pavana Murthy <pvlrpm@gmail.com>
Date: Saturday, April 28, 2018 at 12:45 AM
To: "David Smith (djsmith)" <djsmith@cisco.com>
Cc: idr wg <idr@ietf.org>, Pradosh Mohapatra <mpradosh@yahoo.com>, "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>, "ju1738@att.com" <ju1738@att.com>, "jhaas@juniper.net" <jhaas@juniper.net>, "akarch@cisco.com" <akarch@cisco.com>, "sairay@cisco.com" <sairay@cisco.com>, "pmohapat@cumulusnetworks.com" <pmohapat@cumulusnetworks.com>, "wim.henderickx@alcatel-lucent.be" <wim.henderickx@alcatel-lucent.be>, "Simpson, Adam 1. (Nokia - CA/Ottawa)" <adam.1.simpson@nokia.com>, "mtexier@arbor.net" <mtexier@arbor.net>
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hello,
  Including all the authors mentioned in draft-ietf-idr-flowspec-redirect-ip-02, as the alias did not work. Also pasting doubts again here.

In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the following procedure is mentioned to validate the extended community of 'Flowspec
redirect to IP'.


   BGP speakers that support the extended communities defined in this

   draft MUST also, by default, enforce the following check when

   receiving a flow-spec route from an EBGP peer: if the received flow-

   spec route has a 'redirect to IP' extended community with a 'target

   address' X (in the global administrator field) and the best matching

   route to X is not a BGP route with origin AS matching the peer AS

   then the extended community should be discarded and not propagated

   along with the flow-spec route to other peers.



I have 2 doubts related to this statement.



What is 'origin AS' here? Is it the AS no. that is first added to the AS_PATH?
In the previous version of the draft its mentioned as the last AS in the AS_PATH.
Is it the last AS no. that has been added to the AS_PATH or the last AS no. from left in AS_PATH?



What if the redirect target X is directly connected or reachable by a static route and its not advertised by EBGP?

Do we need to consider that action invalid in that case?


Thanks,
Pavana.


On Sat, Apr 28, 2018 at 10:10 AM, PVLR Pavana Murthy <pvlrpm@gmail.com<mailto:pvlrpm@gmail.com>> wrote:
Hi Dave,
   Thanks for the reply and including respective draft author aliases.

I went through the latest draft-ietf-idr-bgp-flowspec-oid-06. It calls the first AS the Origin AS. Is it so?
If that's the case, the validation will fail for any 'redirect IP' actions coming from the AS other than neighbor AS. Is that the intention?
Also In  draft-ietf-idr-flowspec-redirect-ip-00.txt, instead of 'origin AS', the word 'last AS' is used.It is confusing.   Does the validation need to consider the first AS or last AS?


Regarding my second doubt, I could not get any pointers from  draft-ietf-idr-bgp-flowspec-oid-06 .  Do we need to consider only BGP routes always?


Thanks,
Pavana.


On Sat, Apr 28, 2018 at 3:37 AM, David Smith (djsmith) <djsmith@cisco.com<mailto:djsmith@cisco.com>> wrote:
Hi Pavana,

Your points are valid. With that said, I’ll defer you to draft-ietf-idr-bgp-flowspec-oid-05 (and later) and, specifically, section 4 (revised validation procedure) which addresses your points below.

Co-incidentally, a WG last call was issued for draft-ietf-idr-bgp-flowspec-oid-06 yesterday.

Regards,

/dave


From: PVLR Pavana Murthy <pvlrpm@gmail.com<mailto:pvlrpm@gmail.com>>
Sent: Friday, April 13, 2018 1:51 AM
To: idr wg <idr@ietf.org<mailto:idr@ietf.org>>; pmohapat@cumulusnetworks.com<mailto:pmohapat@cumulusnetworks.com>; David Smith (djsmith) <djsmith@cisco.com<mailto:djsmith@cisco.com>>
Subject: Validation for BGP Flow-Spec Redirect to IP Action

Hello,
  In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the following procedure is mentioned to validate the extended community of 'Flowspec
redirect to IP'.



   BGP speakers that support the extended communities defined in this

   draft MUST also, by default, enforce the following check when

   receiving a flow-spec route from an EBGP peer: if the received flow-

   spec route has a 'redirect to IP' extended community with a 'target

   address' X (in the global administrator field) and the best matching

   route to X is not a BGP route with origin AS matching the peer AS

   then the extended community should be discarded and not propagated

   along with the flow-spec route to other peers.



I have 2 doubts related to this statement.



What is 'origin AS' here? Is it the AS no. that is first added to the AS_PATH?
In the previous version of the draft its mentioned as the last AS in the AS_PATH.
Is it the last AS no. that has been added to the AS_PATH or the last AS no. from left in AS_PATH?



What if the redirect target X is directly connected or reachable by a static route and its not advertised by EBGP?

Do we need to consider that action invalid in that case?





Thanks,

Pavana.