Re: [sidr] IXP and Route Server and Next Hop transparency

Robert Raszuk <raszuk@cisco.com> Sat, 09 July 2011 23:23 UTC

Return-Path: <raszuk@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2868C21F8AC4 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 16:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.632
X-Spam-Level:
X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5OfuknIFSZS for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 16:23:17 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5421F8A6F for <sidr@ietf.org>; Sat, 9 Jul 2011 16:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1710; q=dns/txt; s=iport; t=1310253797; x=1311463397; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xQxuPNPilKZS1niT2v4XBmKnS/1JKLZ0cYNOMPclEgA=; b=SO2c5zhVirfysWrztwCDxTJdFrVb6jObjvlQK21UHnYhBS7kHNrED3Vv feu8+wOzrduorPrum1qUTIKwQSStrX7Sl+k/Jt4EiwVU9XIV9+UNcPBhs ZWTPhhTipIynmfSDG0UOPrAF1pOIe6jbkPfDQUCarwEPY1YSysexl97a3 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKbiGE6rRDoJ/2dsb2JhbABTp1N3iHqlE4MVDwGZTIY6BJJUhH6LSw
X-IronPort-AV: E=Sophos;i="4.65,506,1304294400"; d="scan'208";a="1401185"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2011 23:23:17 +0000
Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p69NNF0q010140; Sat, 9 Jul 2011 23:23:15 GMT
Message-ID: <4E18E2EB.3040602@cisco.com>
Date: Sun, 10 Jul 2011 01:23:23 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Sandra Murphy <Sandra.Murphy@sparta.com>
References: <012601cc3d54$8f07c4e0$ad174ea0$@highwayman.com> <m2y609kptw.wl%randy@psg.com> <014001cc3d74$319571c0$94c05540$@highwayman.com> <m2pqlklw3v.wl%randy@psg.com> <014a01cc3d7f$6312f730$2938e590$@highwayman.com> <m2oc14ljh7.wl%randy@psg.com> <017d01cc3da0$9f8cd390$dea67ab0$@highwayman.com> <4E17646A.1050600@cisco.com> <Pine.WNT.4.64.1107091843190.3744@SMURPHY-LT.columbia.ads.sparta.com>
In-Reply-To: <Pine.WNT.4.64.1107091843190.3744@SMURPHY-LT.columbia.ads.sparta.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sidr@ietf.org
Subject: Re: [sidr] IXP and Route Server and Next Hop transparency
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: raszuk@cisco.com
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: Sat, 09 Jul 2011 23:23:18 -0000

Hi Sandy,

> The owner of the advertised prefix doesn't have ownership of the next
> hops along the path. nor does it have anything to say about the
> legitimacy of next hops along the path.
>
> There's this whole "third part next hop" concept which would make
> determining legitimacy of the next hop complicated.

Third party next hop (typical in IX cases) assures that the ownership of 
the next hop stays unchanged. So I would observe that this would make it 
actually easier there.

Moreover there are deployed applications which specifically mandate to 
not change next hop across AS boundaries. As example I could bring 
Inter-AS option C for L3VPNs. Note that there can be transit ASes in the 
path too. So how are we going to assure a customer of such service that 
the advertising prefix from customer site attached to AS 1, transiting 
via AS 2 and terminating at AS 3 got to the final site on the other side 
uncompromized ?

Maybe one should ask the bigger question: Is BGPSec as is being defined 
in SIDR applicable to other address families other then 1/1|2 and 2/1|2 
which still carry IP prefixes or is it out of scope ?

How about Internet as a VPN (aka Internet in a VRF scenarios) where 
internet routes may travel as vpnv4/vpnv6 updates ?

How about those address families in BGP which are designed to carry 
control plane information between domains for example: bgp flowspec or 
rt-constrain ?

I am just trying to understand if we are talking more of enhancements to 
bgp security (bgp being the protocol) or perhaps about just limiting the 
SIDR scope to build a new layer for controlling traditional Internet 
prefix propagation ?

Many thx.
R.