Subject: Re: [Idr] [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

From: Rob Foehl <[email-masked]>
Date: Wed, 2 Oct 2019 19:45:15 -0400 (EDT)

On Thu, 26 Sep 2019, Jeffrey Haas wrote:
>> On Sep 26, 2019, at 6:43 PM, Warren Kumari <[email-masked]> wrote:
>>
>> This is nice, but what would make it more useful would be if it also
>> reported if there are *useful* AS_SETS / if the AS_SET means anything.
>>
>> For example, from Jared's email below:
>> AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
>> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path.
>
> This one is on the buggy end of things, but still reasonably valid.  It smells like something that passed through remove-private of some flavor.

I'd wager this explains nearly all of the "set of one" instances seen in 
the wild -- there are currently a half dozen or so with a set containing a 
private AS at the end of the path.

> It'd be interesting to find out what code these folk are running. Hopefully not one of my bugs. :-)

I've never had an interaction with AS_SET that could be described as 
anything other than broken -- like, ever, from any vendor.  I'd prefer to 
see them disappear entirely, but if that doesn't happen, at least having a 
"no-as-sets-under-any-circumstances" policy knob would be helpful...

-Rob

---

From: Jared Mauch <[email-masked]>
Date: Wed, 2 Oct 2019 19:48:15 -0400

> On Oct 2, 2019, at 7:45 PM, Rob Foehl <[email-masked]> wrote:
> 
> I'd wager this explains nearly all of the "set of one" instances seen in the wild -- there are currently a half dozen or so with a set containing a private AS at the end of the path.
> 
> I've never had an interaction with AS_SET that could be described as anything other than broken -- like, ever, from any vendor.  I'd prefer to see them disappear entirely, but if that doesn't happen, at least having a "no-as-sets-under-any-circumstances" policy knob would be helpful…

I think back in the days when ANS was still a major player and if you were routed depended upon did you follow the rules that Curtis required, they were still valid.  I think in most modern cases they’re likely not intended or some weird hybrid AS_SET+CONFED setup, likely with remove-private as Jeff speculates.

I’ve not yet composed e-mail to the people originating these, but it shouldn’t be hard to contact them.  They may not know about the issue.  (Generally operators lack awareness of what they route).

- Jared

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Oct 2019 16:25:15 -0400

On Wed, Oct 02, 2019 at 07:45:15PM -0400, Rob Foehl wrote:
> anything other than broken -- like, ever, from any vendor.  I'd
> prefer to see them disappear entirely, but if that doesn't happen,

As Jared noted, this was more of a common thing back-in-the-day.

For properly operating proxy aggregation, you'd generally hope that all
contributing networks were properly behind the aggregating party.  However,
as the Internet has gotten more meshy, those topological considerations
don't apply anywhere near as much.

As this torches and pitch-forks campaign against as-set continues, operators
will have to figure out whether they're really happy with the two impacts:
- No proxy aggregation, ever?
- Lie about the AS_PATH when you do it.

Today you can at least infer that proxy aggregation is happening.

The second point has entertaining impact vs. RPKI, so that's the likely
forcing function.

> at least having a "no-as-sets-under-any-circumstances" policy knob
> would be helpful...

It's a fine policy knob, and I'm more supportive of that in general.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 3 Oct 2019 22:13:04 +0000

AS_SET can be used to reduce the AS-PATH length or to hide the actual path
but still prevent as-path loops.
AS_SET can be used to prevent distribution of a route to the ASNs in the set
without overgrowing the as-path length.
This makes the Pilosov-Kapela BGP hijack easier to do.
I support deprecation, but realize that it will never be removed :(

Regards,
Jakob.

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Thursday, October 3, 2019 1:25 PM
To: Rob Foehl <[email-masked]>
Cc: IDR <[email-masked]>; GROW WG <[email-masked]>; Warren Kumari <[email-masked]>; [email-masked]
Subject: Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

-- Jeff

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 23 Oct 2019 15:45:17 +0000

Earlier in this thread, there was discussion about some measurements that were shared  (by Jared, Warren, myself).
Jeff's suggestion: why don't we list all routes with AS_SET in addition to the stats.
Now we have a detailed analysis (thanks once again to Lilia Hannachi my colleague at NIST):
https://www.nist.gov/sites/default/files/documents/2019/10/23/detailed-as_set-analysis.txt   

The analysis includes the following:
1. Summary stats
2. List of ASes (AGGREGATORs) Ranked according to # Routes with AS_SET
(including the organization name of the AGGREGATOR)
3. List of routes with AS_SET that seem meaningless or malformed.
4. List of routes with AS_SET that seem meaningful.
3. List of all routes with AS_SET (listed per AGGREGATOR)

The summary stats are copied here, but please see other details at the link provided.

AS_SET ANALYSIS (OREGON 2019-10-03:00)
The Routeviews OREGON collector peers with 43 ASes. 

Summary stats:

	Total # Updates : 30052331
	# Updates with AS_SET : 14348
	Percentage of Updates with AS_SET : 0.048%
	# Total # ASes (globally) : 66205
	# ASes that create Updates with AS_SET : 144
	% ASes that create Updates with AS_SET : 0.218%

	# Routes with AS_SET (after eliminating AS path redundancy): 477
	Explanation: These are routes with unique {prefix, AS_SET, 1st AS after AS_SET, AGGREGATOR} combinations.

Out of the 477 routes with AS_SETs:
	*** Identifying Routes with AS_SET that seem meaningless or malformed ***
	# Routes with only one AS in AS_SET : 383
	# Routes with Reserved ASN in AS_SET : 131
	# Routes with common AS in the AS_SEQUENCE and AS_SET : 139
	# Routes with repeated ASes in the AS_SET : 0
	# Routes that are /24 prefix (aggregate) announcements : 239
	Total # Routes that seem meaningless or malformed : 456

	Total # Routes that seem meaningful : 21

	Distribution of # unique ASes in the AS_SET : 1:383, 2:68, 3:14, 4:5, 5:2, 6:3, 23:1, 31:1

	# Routes with AS_SET where AGGREGATOR does not match the right most AS in AS_SEQUENCE : 47

	# Routes with unique {prefix, AS_SET, AGGREGATOR} : 469
	# Routes with unique {prefix, AS_SET} : 455

*** When there is an AGGREGATOR but no AS_SET ***
	# Unique prefixes (with or without AS_SET) : 826535
	# Unique prefixes without AS_SET but with AGGREGATOR: 75698
	% Unique prefixes without AS_SET but with AGGREGATOR: 9.158%

Sriram

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2019 14:20:21 -0400

Sriram,

> On Oct 23, 2019, at 11:45 AM, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]> wrote:

The three of these have a strong feeling of bugs related to aggregation interacting with either confederations or private internal AS numbers and remote-private.

Operators with diverse labs may wish to play around and see what they can generate. :-)
(I don't claim our implementation is bug-free here.  But I know what I'd look for if doing a code audit.)

> 	# Routes with repeated ASes in the AS_SET : 0

This one is somewhat expected.  The practice of canonicalizing sets in most people's code base should generally ensure that if you have a single sane BGP implementation in the path of the route to the observatory that the duplicates would be pruned.

-- Jeff

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Oct 2019 16:38:14 -0400

Thank you Sriram and Lilia -- this is helpful / useful.

I wonder if the people who configured the 21 "Routes that seem
meaningful" still know that they are doing this, or if it is a lurking
horror....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf