Subject: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03?

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Oct 2021 10:06:42 +0200

Dear all,

draft-ietf-sidrops-8210bis-03 defines the ASPA PDU as follows:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |        zero         |
   |    2     |    11    |                     |
   +-------------------------------------------+
   |                                           |
   |                 Length                    |
   |                                           |
   +-------------------------------------------+
   |          |          |                     |
   |  Flags   |   zero   |  Provider AS Count  |
   |          |          |                     |
   +-------------------------------------------+
   |                                           |
   |    Customer Autonomous System Number      |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |    Provider Autonomous System Numbers     |
   |                                           |
   ~-------------------------------------------~

I believe that there is a potential issue here with very large
ranges of providers. Theoretically up to 2^32 four byte providers
ASNs could be specified. Because of the length of the provider
AS count field that is limited here to 2^16 - still a large
number.

Would it make sense to support ranges as well? To avoid sending
everything as ranges (which would cause some overhead) we could
have:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |        zero         |
   |    2     |    11    |                     |
   +-------------------------------------------+
   |                                           |
   |                 Length                    |
   |                                           |
   +-------------------------------------------+
   |          |          |                     |
   |  Flags   |   zero   |  Provider AS Count  |
   |          |          |                     |
   +-------------------------------------------+
   |                                           |
   |    Customer Autonomous System Number      |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |    Provider Autonomous System Numbers     |
   |                                           |
   +-------------------------------------------+
   |          |          |                     |
   | reserved | reserved | Provider Range Count|
   |          |          |                     |
   +-------------------------------------------+
   |                                           |
   |  Provider Autonomous System Range Start   |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |  Provider Autonomous System Range End     |
   |                                           |
   ~-------------------------------------------~

Kind regards
Tim

---

From: Job Snijders <[email-masked]>
Date: Wed, 13 Oct 2021 11:08:54 +0200

Hi Tim,

> everything as ranges (which would cause some overhead) we could

Ranges do not make sense to me. Which ISP or IXP on this planet has a
set of providers which coincidentally also form a coherent numerical
range?

Has anyone ever said "I buy transit from AS 1 upto including 1000"?

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Oct 2021 10:36:27 +0100

> Has anyone ever said "I buy transit from AS 1 upto including 1000"?

More to the point, what would happen if someone created an object which 
stated that they bought transit from AS1 up to AS4294967294?

Nick

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Oct 2021 11:50:36 +0200

> On 13 Oct 2021, at 11:36, Nick Hilliard <[email-masked]> wrote:
> 
> More to the point, what would happen if someone created an object which stated that they bought transit from AS1 up to AS4294967294?

Indeed..

..or if..

- they want to say (for misguided reasons) consider *any* ASN after me valid
- they want to authorise all private ASNs
- they hold a range of public ASNs

- they are bad actors and want to see what this would do to your RP, RTR session and/or router stack.

Regarding the latter support for ranges only gets you so far of course.. as they could have ranges
of 2 elements, one blank, and repeat ad nauseam. That is still a 170kb message (2/3 of 64k * 4b).
Limits may be desirable somewhere, but of course any limit would be arbitrary even if it's reasonable.

I don't claim to have the full answer, but I think this needs some consideration.

> 
> Nick
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 13 Oct 2021 11:56:09 +0200

> stated that they bought transit from AS1 up to AS4294967294?
 
Since this is a nonsensical request the ASPA draft needs to be  adjusted
and just plain not allow it. Please stop adding features that are complex
to implement and not needed. BGPsec has the same issue of supporting AS
ranges for no valid reason. It only adds an attack vector to the
protocol.

-- 
:wq Claudio

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 13 Oct 2021 12:08:12 +0200

> - they want to say (for misguided reasons) consider *any* ASN after me valid

This is most probably abuse and so should be prevented. Please show real
live prove that this is absolutly necessary for some case of operation.

> - they want to authorise all private ASNs

Private ASNs should not show up in the DFZ. Again this does not improve
ASPA adoption and so it should just not be allowed.

> - they hold a range of public ASNs

How large of a range are we talking here? Even with a range of 100ASNs can
be easily encoded individually without any problems.

Please remember that the BGP implementations also need to implement the
checks and having a mix of range and indiviual ASNs will not help them.
Again it is better to keep it simple.
 
> - they are bad actors and want to see what this would do to your RP, RTR session and/or router stack.

This is the reason why ranges should just not exist. They add complexity
and make the hole system more error prone.

> I don't claim to have the full answer, but I think this needs some consideration.

I think real world data needs to show that ranges are indeed needed and
not only an extension that will be abused.

-- 
:wq Claudio

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Oct 2021 11:14:08 +0100

Claudio Jeker wrote on 13/10/2021 10:56:
> and just plain not allow it

I would be in favour of this for exactly the reasons you mentioned.  It 
adds nothing useful.

Nick

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Oct 2021 12:17:36 +0200

> On 13 Oct 2021, at 12:08, Claudio Jeker <[email-masked]> wrote:
> 

Ranges here, and in the ASPA profile encoding, do not cause the problem. They are a
way to encode consecutive ASNs more efficiently.

If you want to have a limit on the amount of provider ASNs that can be validly
specified, then I have no objection to that - I just said that limits will
de-facto be arbitrary. It's still better though in my opinion to have well defined
limits even if they are arbitrary - otherwise implementations will each invent their
own.

If there is a reasonable limit then the RTR PDUs can remain simple, but I would
still argue for the encoding (other thread) because it's cheap to do and well
understood - it leverages RFC 3779 and is not inventing anything new.

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Oct 2021 11:32:26 +0100

> way to encode consecutive ASNs more efficiently.

agreed but there are few, if any, real-life cases where asn ranges would 
be used as a primitive in terms of specifying routing policy, and in 
particular if the ASN ranges specify lists of providers.

I'd be quite keen to see this explicitly disallowed in terms of ASPA. 
If it's not there, the tiny potential handful of organisations who might 
ever need this would be inconvenienced to a minor extent.  If the 
feature is there, it complicates overall end-to-end processing and opens 
up a bunch of really messy corner cases which would need to be 
explicitly disallowed in code anyway (unless you wanted code stacks to 
explode arbitrarily).

Nick

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Oct 2021 12:34:31 -0700

>> Ranges here, and in the ASPA profile encoding, do not cause the
>> problem. They are a way to encode consecutive ASNs more efficiently.
> 
> agreed but there are few, if any, real-life cases where asn ranges
> would be used as a primitive in terms of specifying routing policy,
> and in particular if the ASN ranges specify lists of providers.

excuse my terseness; but for the three corner cases on the planet, who
the heck needs this rabbit hole?

randy