Subject: [Sidrops] MaxLength Considered Harmful to the RPKI?

From: Job Snijders <[email-masked]>
Date: Tue, 8 Nov 2016 17:11:54 +0100

Hi group,

I stumbled across a interesting publication called "MaxLength Considered
Harmful to the RPKI" which raised questions. Given that we don't have
path validation, and origins are easily spoofed, this is a relevant
operational consideration.

You can download the paper here: https://eprint.iacr.org/2016/1015.pdf

Cutting to the chase: in chapter 7 the authors put forward: "We
therefore suggest eliminating the maxLength attribute..." (followed by
some alternative ideas).

I took the suggestion and deployed according routing policy in AS 8283 -
a BGP playground in Amsterdam. At first I was dropping all non-exact ROA
matching routes, but quickly had to revert to just BGP Community
tagging.

IPv4:
	as8283-router$ birdc 'show route where (8283,100) ~ bgp_community primary'  | wc -l
	21300
	(3.5% of the IPv4 routes in the Default-Free Zone)

IPv6:
	as8283-router$ birdc6 'show route where (8283,100) ~ bgp_community primary'  | wc -l
	1261
	(3.7% of the IPv6 routes in the Default-Free Zone)

I wrote this small proof-of-concept tool to take RPKI data and convert
it into a static configs so I can easily toy with different ideas in a
real world deployment: https://github.com/job/rtrsub

So today, November 2016, flat out ignoring MaxLength will break your
connectivity, but MaxLength can't be fully trusted either.

Thoughts?

Kind regards,

Job

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 08 Nov 2016 13:16:46 -0300

Thanks Job,

I’ll go through the publication. As anecdotal evidence, many of our 
training attendees find maxLen quite confusing, for some reason (I 
don’t have a proper explanation). In fact, many end up doing maxLen=32 
(ipv4 of course) for everything.

-Carlos

On 8 Nov 2016, at 13:11, Job Snijders wrote:

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 17 Nov 2016 14:01:50 +0900

Hi Job,

First of all: good read. And I actually agree that the MaxLength attribute should be eliminated.

As the document explains authorising more specific announcements that you do NOT do, makes it easy for attackers to spoof your ASN and do the more specific announcement. Therefore you should NOT authorise these gratuitously, and "Relying Parties" should treat more specific as invalid in their routers. That way the attack is limited to spoofing your AS and *matching* your announcement, this is not a full solution of course but it's a much better place since such attacks are much less effective. Going further: sometimes I hear people say that origin validation without path validation is pointless, but I think this shows that there is incremental value in origin validation alone (on top of protecting against mistakes where the ASN is not spoofed).

So in short: you should only authorise your actual announcements, and I would support an update to the spec to get rid of MaxLength.

Operational experience shows that MaxLength is highly confusing to users, and it doesn't improve usability in significant ways.

For what it's worth in our RPKI deployment we allow setting MaxLength since it's in the spec, but we do not encourage it. In fact we just encourage users to authorise the BGP announcements that they actually want to do. We help our users by showing them the announcements that we see in BGP, but of course users are free to add additional authorisations for back-up routes, or planned announcements that we do not see, *and* of course users can also choose to *not* authorise announcements that they believe should be invalid.

If we see an announcement that is invalid because of maxlength we offer two options: first (default) create an authorisation for just this additional announcement, or indeed modify MaxLength. I don't have access to this right now because I am travelling, but I can get some statistics on what our users do over the next weeks and report that.

The original intent of MaxLength was for this to be a short-hand so that in a case like: you have a IPv4 /20 and you do announce all the /24s, you can set MaxLength so that you can have 1 ROA instead of 16. But.. I really don't think this is a strong use case. If you really want all 16 ROAs, you can create them individually (or script that).

The other use case that we have encountered for MaxLength is cases where holders of a bigger prefix do more specific announcements from time to time. And they do not want to go into the UI every time and change things manually. We defer these users to using our API instead. I.e. you can modify your network management tools to automatically create the authorisations as soon as do more specific announcements.

Cheers
Tim

> On 09 Nov 2016, at 01:11, Job Snijders <[email-masked]> wrote:
> 
> Hi group,
>