Re: [Sidrops] [GROW] IXP Route Server question

Nick Hilliard <nick@foobar.org> Tue, 08 March 2022 21:28 UTC

Return-Path: <nick@foobar.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E503A17DE; Tue, 8 Mar 2022 13:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 5hikJwiOZhjk; Tue, 8 Mar 2022 13:28:16 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F413A0EE3; Tue, 8 Mar 2022 13:28:15 -0800 (PST)
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) by mail.netability.ie (Postfix) with ESMTPSA id F07089CEB1; Tue, 8 Mar 2022 21:28:10 +0000 (GMT)
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Cc: "grow@ietf.org" <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <0db7749f-66fd-5def-a8bb-3ee316cf2ca1@foobar.org>
Date: Tue, 8 Mar 2022 21:28:09 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.54
MIME-Version: 1.0
In-Reply-To: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tbEv2A3RFG8iBeTyqguBKVLNCas>
Subject: Re: [Sidrops] [GROW] IXP Route Server question
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2022 21:28:19 -0000

Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36:
> This question has relevance to the ASPA method for route leak
> detection.
> 
> Is it possible that an ISP AS A peers with a customer AS C via a
> non-transparent IXP AS B?
> IOW, the AS path in routes propagated by the ISP A for customer C's
> prefixes looks like this:  A B C.
> I.e., can the AS of a non-transparent IXP/RS appear in an AS path in
> the middle between an ISP and its customer?

Almost all RS's are transparent these days.  Usually IXPs go to lengths 
to ensure that the RS ASN doesn't appear in the AS path.

Some organisations provide transit over IXPs, but it's a minority thing. 
It would be very peculiar if an organisation provided transit over an 
IXP via an RS.

Some organisations provide transit to ASNs over a direct physical 
connection while maintain peering with their customer over an IXP port. 
Usually this happens by accident, but occasionally it can happen by design.

The answer to your question is that it would be technically possible, 
but it would be so peculiar and stupid that it should be considered a 
mistake in the situations where it was intentional. In all other 
situations, it would be a leak.  Generally it would be safe to assume 
that this sort of configuration was in error.

Nick