[sidr] draft-sriram-route-leak-protection-00

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 28 July 2014 01:16 UTC

Return-Path: <jheitz@cisco.com>
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 B6E691B27D5; Sun, 27 Jul 2014 18:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 l5lu69aqbWwS; Sun, 27 Jul 2014 18:16:08 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2D61B27D3; Sun, 27 Jul 2014 18:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6517; q=dns/txt; s=iport; t=1406510168; x=1407719768; h=from:to:subject:date:message-id:mime-version; bh=gQCMnGHIXMkSQwdcEEEej+KlQ5KHY8BfLlaeSVhfVFg=; b=iQyoypvE2TyFhMqQu7D7VZqww5TLhcrWAEsth1megNB0tpFp9FnIhpbg jOs4VOG/Gu5s58PulVRetmkeEWNLF+3MftR881S0IDE5EeDu1BFCZmiNo Fr8nZCjOllh0xvrO9POjlmFSFxrvZOIhyH1IhdoLCSPg1K72K78sYwbH0 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAP2j1VOtJV2Y/2dsb2JhbABZgkdHUlvTIwGBERZ3hAUBBC1FGQEqViYBBAEaE4gnvRUXjxuDZ4EbBbAYg0mCMQ
X-IronPort-AV: E=Sophos;i="5.01,745,1400025600"; d="scan'208,217";a="343238857"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2014 01:16:07 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6S1G671017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 01:16:06 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 27 Jul 2014 20:16:06 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: IETF SIDR <sidr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Thread-Topic: draft-sriram-route-leak-protection-00
Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQ==
Date: Mon, 28 Jul 2014 01:16:06 +0000
Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.66.206]
Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/0IEtqxtDyhJc30oW_m-q8Attsq8
Subject: [sidr] draft-sriram-route-leak-protection-00
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: Mon, 28 Jul 2014 01:16:09 -0000

In GROW, at the mike, I proposed another solution:

Add a new attribute that means "this route may be advertised up".
This attribute must be signed by the originator of the route.

Add a second attribute that means "The first attribute was added"
This attribute must be included in the BGPSEC signature.

If an AS asserts that the route can no longer be advertised up,
it simply removes the first attribute along with its signature.

Since the first attribute must be signed by the originator, no one else can add it back.

Now, an AS that considers itself a provider of the advertised route to the peer from which it received the advertisement can filter on the presence of the second attribute and the lack of the first to prevent the leak.

The advantage of this solution is that it will not expose the customer-provider relationship to any customers.

--Jakob