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

Sandra Murphy <Sandra.Murphy@sparta.com> Sat, 09 July 2011 23:05 UTC

Return-Path: <Sandra.Murphy@cobham.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 8B73721F8AC4 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 16:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 fblGrOYVvORk for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 16:05:30 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF621F8A59 for <sidr@ietf.org>; Sat, 9 Jul 2011 16:05:29 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p69N5Rbt016366; Sat, 9 Jul 2011 18:05:27 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p69N5RUC001734; Sat, 9 Jul 2011 18:05:27 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([76.111.96.30]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Jul 2011 19:05:24 -0400
Date: Sat, 09 Jul 2011 19:05:26 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: Robert Raszuk <raszuk@cisco.com>
In-Reply-To: <4E17646A.1050600@cisco.com>
Message-ID: <Pine.WNT.4.64.1107091843190.3744@SMURPHY-LT.columbia.ads.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>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 09 Jul 2011 23:05:24.0840 (UTC) FILETIME=[AF8B7E80:01CC3E8C]
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
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:05:30 -0000

On Fri, 8 Jul 2011, Robert Raszuk wrote:

>
> On the previous post I just wanted to limit such bgpsec less exchange to stub 
> customers only. But I agree and stand corrected that if we solve it for all - 
> transit included - then there is no need to make any special treatment for 
> stubs. Question withdrawn.
>
> ---
>
> However I would like to ask for some clarification on why bgpsec is all about 
> securing advertised nets and does not (at least to the best of my knowledge) 
> certify that such prefixes have been advertised with legitimate next hops 
> (the one which the prefix owner really owns). I browsed the respective drafts
> and did not find a trace of such.

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.

--Sandy, speaking as regular ol' wg member


>
> If we talk about RS in particular such RS is not in the data path hence it is 
> not modifying next hops as received from his clients.
>
> How are we going to protect the paths from compromised RS where the prefixes 
> are advertised correctly but next hops are bogus ? What's worse client's 
> customers connected via such RS may have chosen such paths as best even if 
> they have alternatives ...
>
> Thx,
> R.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>