Re: [sidr] [GROW] Route leaks

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Thu, 31 July 2014 01:21 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960EA1A039F; Wed, 30 Jul 2014 18:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 cGvcu66UjPVn; Wed, 30 Jul 2014 18:21:11 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DC31A016D; Wed, 30 Jul 2014 18:21:11 -0700 (PDT)
Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0276.namprd09.prod.outlook.com (25.160.80.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 01:21:09 +0000
Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Thu, 31 Jul 2014 01:21:09 +0000
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Christopher Morrow <christopher.morrow@gmail.com>, Doug Montgomery <dougm.work@gmail.com>
Thread-Topic: [GROW] Route leaks
Thread-Index: AQHPqC+L+pthRCwHxUq5zj1Ayx7LMZuxKGaAgAAEMYCAAAJggIAAHfwAgAFhWYCAA64xgIADA4Og
Date: Thu, 31 Jul 2014 01:21:08 +0000
Message-ID: <2c1f9feb72ff4042b3ff329292b93ea2@BN1PR09MB0274.namprd09.prod.outlook.com>
References: <CAMaMmnn4xVWeTetkpjCTPUqNnD6PtrB7Rj72gbdmiRTwZ2gObQ@mail.gmail.com> <CAGQUKcdyHCx-Lt1=V8jeFfCvz+CyT4=-GuW=3A=0qu+UUNH-Kw@mail.gmail.com> <8D378E8B-13DB-4733-91B2-5F9D000AF454@puck.nether.net> <CAGQUKcc-Qv=+HhoYRroO3WKWWzZwWNSE8aM_TY9WwzDuJWjQkw@mail.gmail.com> <CAL9jLaYkA_dfJwp1Jsgiw4YVZbTLLZ3JYO5Mwvj72WnQZhTE+g@mail.gmail.com> <CAMaMmnmqC_ei5=k=y4ddm4-KPnFJ_8QVb7NCCM9_Tx=rbQnqbg@mail.gmail.com> <CAL9jLaZs6W5OJkOYXDZzPRukhkDvZ7dD1NY689besCG1icCacA@mail.gmail.com>
In-Reply-To: <CAL9jLaZs6W5OJkOYXDZzPRukhkDvZ7dD1NY689besCG1icCacA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.6.140.100]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(52314003)(51704005)(199002)(189002)(107046002)(105586002)(95666004)(77096002)(83072002)(33646002)(85306003)(99286002)(106356001)(79102001)(21056001)(76482001)(80022001)(76176999)(101416001)(93886003)(106116001)(86362001)(50986999)(74662001)(81542001)(46102001)(74502001)(4396001)(31966008)(83322001)(2656002)(85852003)(54356999)(20776003)(66066001)(77982001)(76576001)(99396002)(92566001)(81342001)(87936001)(74316001)(64706001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0276; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Khada5ntBP48R531XiU3NRncKkc
Cc: "grow@ietf.org grow@ietf.org" <grow@ietf.org>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Subject: Re: [sidr] [GROW] Route leaks
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 01:21:13 -0000

>> In some ways I think building a taxonomy of scenarios that could be 
>> called route-leaks is useful,  but I do think there is a danger is 
>> overly fixating on a precise definition of a commonly used term ...
>
> The state today is: "I know it when I see it"
> which isn't super helpful in the 'gosh, it'd sure be nice to stop 
> having ISPA leaking my routes all over creation' fight.

Chris,

If we step back for a moment and look at how we tackled prefix hijacks, 
there is a valuable lesson there that applies also to tackling route leaks.

Initially, we classified prefix hijacks into two types:
1. Prefix hijack,
2. Subprefix hijack.
This was based on commonly observed hijack incidents.

We started looking at solutions, and determined that generating 
ROAs for the prefixes would be a solution for the first one.
Then we thought a bit more, and determined that specifying 
MaxLength in the ROA would be a partial solution for the second one.

After we included ROAs in our design, we realized that there are these 
two new classes of prefix hijacks that try to defy ROAs and maxLength:

3. Subprefix hijack where maxLength is not violated, 

4. Faked-origin (prefix/subprefix) hijack.

Thus, our understanding evolved to classify prefix hijacks into four types, 
each calling for possibly a different solution component.
This was, in part, the consequence of the solutions we were considering.
Then we thought that perhaps we can put two ASes in the ROA (origin AS and the second AS) 
to try to disadvantage the faked-origin hijacks. 
Because then the hijacked route is at least two hops longer compared to the legitimate one.
But eventually, we decided to do the path signatures since we had to protect AS path anyway, 
and path signatures approach also solved prefix hijacks of Type 3 and Type 4 above
-- because they are essentially path modifications.
Viola: Now we have the solution for all four classes of hijacks plus full AS path protection!
(Granted -- our solution is not yet complete because it doesn't solve route leaks.)

The essential lesson that I think we learned from the above is that 
classification based on observed or easily conjectured scenarios works!
So yes, classify and conquer should be the motto here.
As is evident from the above, starting to propose solutions based on what we know
-- even if it is partial knowledge -- is helpful.
And with some solution components in place, further taxonomy naturally evolves 
to provide greater clarity into problem definition and classification.

Sriram