Public shaming list for ISPs announcing other ISPs IP space by mistake

Mailman List Mirror (Read Only)
21

Depends who you ask. Some think applying the dns model to bgp (i.e.
within protocol) will ultimately place too great a burden on routing
hardware & associated 'state' infrastructure. I tend to agree with
that position. Perhaps the model we ought to be considering is
something more akin to an external mechanism that automated systems
(i.e. things to crank out prefix-lists/as-path lists) could draw from
during 'refresh' periods, solely dedicated to authorizing prefixes
against origin asn and/or as path (or name your $permutation_here).

I.e. if said new system were to fail, it'd be great if it didn't
affect routing in any way (we can live with a few days of stale lists,
I think).

Greene/Schiller, pipe up - this is your torch, right?

-Tk

22

If one were to ignore layer 9 politics, it could be argued the authority/delegation models between DNS and address space are quite analogous.

DNS:

IANA maintains "." ("dig @ns.iana.org . axfr") and delegates portions of the namespace to top-level domain registries
Top-level domain registries delegate parts of their namespaces to second-level domain registries (typically end users)

Address space:

IANA maintains the top-level address registry (http://www.iana.org/assignments/ipv4-address-space/ and http://www.iana.org/assignments/ipv6-unicast-address-assignments) and delegates portions of the address space to RIRs.
RIRs delegate parts of their address space to LIRs/ISPs/end users.

Of course, ignoring layer 9 politics can be a bit challenging.

Regards,
-drc

23

but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services

'Cause there ain't nobody out there to "formally require" this.
Other than ISPs, of course. And that means there will be umpteen
different sets of rules, one set for each ISP.

if you are a new customer and you sign up for bgp, it is
clearly stated in the contract, the customer/provider
requesting this service must maintain objects radb..

In that case, no problem. But what about the contracts that
do NOT state this? Who will change them? What language will
they use? Who will coordinate the changes so that there is
something halfway consistent?

This is the problem Randy refers to when he talks about
formal rigour.

if larger networks adapted to something like this, i think
people would start to follow, as they would have no choice
because they would be cut off from certain routes

Larger peers started this way back about 15 years ago. Very
few followed suit. What makes you think this will change?

Operationally, the Internet is an anarchy. There is no formal
organization of network providers that will set up working
groups to define best practices in routing, in peering, etc.
Instead, we have some areas where there *ARE* organizations
applying formal rigor like email with MAAWG but that only
happens with the real hot button issues. Everything else is
left to simmer away in the anarchy.

In Europe, the network operators that are also in the telecoms
business, formed an organization called ETSI http://www.etsi.org
to address a whole raft of inter-operator issues primarily
focused on standards. There is no good reason why operators
with Internet transit businesses should not form a similar
organization to tackle the problems that come back again and
again on the NANOG list, with only half measure and short term
bandaid fixes being developed.

You will note, that when ETSI was formed there was already an
international telecom standards organization in operation called
the ITU. But it had issues, and so folks went off and set up
something that was more workable. When will NANOG participants
smell the coffee and do likewise? The FCC will not rescue you.

--Michael Dillon

24

I don't think the IRR is so much a hack (it's a tool), but
we're lacking the process and infrastructure to vet/validate
that a given ASN is *authorized* to originate a prefix, and
all of the policy bits (which the IRR has if you use it)
associated with which ASNs should propagate the prefix, etc...

We're lacking the authority and delegation model that DNS
has, I think?

ARIN holds the top of that authority and delegation hierarchy
because they give out the ASnums and IP address blocks. They
also operate a suggestion box here:
<http://www.arin.net/acsp/index.html>
click the yellow button that says "Submit a Suggestion".
There is a formal evaluation process behind that suggestion
box so if there is one or more specific actions that you
believe ARIN should take, then file a suggestion for each
separate action that you want them to do.

To everybody on the list, please do consider making formal
suggestions to ARIN.

--Michael Dillon

25

but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services

Step 1 : Enforce IRR for customers *now*.

Step 2 : Enforce trusted replacement for IRR when available

Step 3 : Profit

Not progressing to step 1 today because you think IRR isn't the best
solution is like not deploying IPv6 because you sat on your arse not
deploying it all these years and justify yourself by denouncing the
protocol on every mailing list and IRC channel at every available
opportunity.

Dave.

26

Step 1 : Enforce IRR for customers *now*.

Step 2 : Enforce trusted replacement for IRR when available

Step 3 : Profit

Not progressing to step 1 today because you think IRR isn't the best
solution is like not deploying IPv6 because you sat on your arse not
deploying it all these years and justify yourself by denouncing the
protocol on every mailing list and IRC channel at every available
opportunity.

[ sorry for preaching. i know you are a fellow choir member ]

for me it separates in to two things

  o what i do with my routers today. as you know, i have been pushing
    the irr and programmatic configuration since the mid '90s. that is
    your step 1.

    we have known how to do this for a decade. we don't need a bunch of
    talk. we need to shut up and hack.

  o what i do with my time. i don't have enough time to spend on both
    hacks and rigor, so i concentrate on the design and implementation
    of long-term formal and rigorous solutions, to which you allude in
    step 2.

randy

27

Right, but I think the bigger issue is not just that "data is in the IRR" but rather "the data is there, and "some organization" has validated that 1) the "owner" is authentic, 2) they own the prefixes they entered, 3) they are authorized to originate the prefixes, and 4) the policies they entered are valid and agreed to by the other parties."

We have to be able to *trust* the data in the IRR, which I assume is one of the biggest impediments to being used by everyone: who's going to validate all that data and how will they do it?

-b

28

And here I thought IANA handed out ASnums and IP address blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and the IETF for specific protocol requirements)...

Regards,
-drc

29

You're missing a step:

  janitor.

  No really, the reason for some leaks isn't because so-and-so was
never a customer, they were. 5 years ago. nobody removed the routes from
the IRR or AS-SET or <insert method here> and now the route is learned via
some other location and it's bypassed your perimiter security and
infiltrated your BGP.

  There's many simple things that makes it seem like it's
an impossible task, but there's a saying, if you're not progressing
you're regressing. If the toolset is too complex or doesn't work,
what are YOU doing to make it better for you and/or your customers?

  - jared

30

We are talking Internet operations, not Internet politics.
You are right as far as that goes but it is ARIN et al. who
hand out ASNums and IP addresses to the network operators
who actually *USE* these numbers in operational networks.
People don't care where the numbers came from, they care
who actually got the rights to use them, and then what
those orgs did with the rights, i.e. an IP addr block owner
may delegate the rights to announce a subset of their space
to a specific ASnum holder.

Etc.

--Michael Dillon

31

And here I thought IANA handed out ASnums and IP address
blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and
the IETF for specific protocol requirements)...

We are talking Internet operations, not Internet politics.

Indeed.

People don't care where the numbers came from, they care
who actually got the rights to use them, and then what
those orgs did with the rights, i.e. an IP addr block owner
may delegate the rights to announce a subset of their space
to a specific ASnum holder.

Yep. And as with DNSSEC, you, as a network operator, get a choice. You can configure a single trust anchor corresponding to the actual address allocation flow and follow a chain of authority down to the leaf (end user or ISP) allocation or you can configure a number of trust anchors and figure out how to deal with cross-certifications resulting from the multiple roots. Ignoring politics, the technically and architecturally cleaner approach is obvious to me. However, as I mentioned, it is challenging to ignore the layer 9 politics.

Regards,
-drc

32

Pardon my ignorance here, but wouldn't it be much simpler if the so
called "tier 1" networks were to do the filtering work so that none of
downstream BGP peers would see the bad announcements ?

If some network in italy sends out some bogus route for a site, this
should be blocked by a few tier 1 networks instead of by everybody at
the bottom of the tree. Yeah, that would mean that folks in italy and
whoever would have direct connections to that italian network would
accept those bad BGP announcements, but the rest of the world would
continue to work.

"tier 1" networks like to brag about their importance within the
internet, perhaps filtering bad announcments should be a responsability
assigned to them, and which would further differentiate them from lesser
networks.

33

Many of them -- most of them? -- do filter, to the extent that they
can. However, they're in a poor position to do a complete job.

If your peer is an end site, it's easy to filter what they send you;
you know (or should know) what address blocks they have. (Verifying
that they actually have the right to announce such blocks is a separate
and difficult question, but I won't get into that here.) But what if
your peer is another Tier 1, or even a lower-level ISP? How can you
filter then? Another ISP can, will, and should announce routes to all
of its customers, and it's quite hard (impossible, really) for the Tier
1s to track their peers' customers. Worse yet, some of these customers
may themselves be ISPs, with their own customers. And if the peer of a
Tier 1 is another Tier 1, it's not even possible to imagine how they'd
know.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

34

TODAY IANA has an operational role in DNS, they don't have
an operational role in Internet routing. This is certainly not layer
9, and most certainly the most fundamental change to the Internet
routing system that RPKI or similar systems would introduce.

To be clear: IANA and RIRs allocate or assign address space
today, they don't control any routing on the Internet (and their
own internal ASNs and IPs don't count).

-danny

35

I agree, how many of you folks that use IRRs have
ever deleted an IRR object? Heck, some ISPs even
add them based on existence of advertised routes.

-danny

36

Pardon my ignorance here, but wouldn't it be much simpler if the so
called "tier 1" networks were to do the filtering work so that none of
downstream BGP peers would see the bad announcements ?

If some network in italy sends out some bogus route for a site, this
should be blocked by a few tier 1 networks instead of by everybody at
the bottom of the tree. Yeah, that would mean that folks in italy and
whoever would have direct connections to that italian network would
accept those bad BGP announcements, but the rest of the world would
continue to work.

Fine idea - how do they build these filter lists?

"tier 1" networks like to brag about their importance within the
internet, perhaps filtering bad announcments should be a responsability
assigned to them, and which would further differentiate them from lesser
networks.

Tragedy of the commons...

-danny

37

A sneak-peek at some (NOT FINAL) relevant data points from
the *ongoing* Infrastructure Security Survey related to this topic
(see below for participation information, if so inclined).

Draw your own conclusions, we'll make ours known in the final
report.

-danny

38

Danny,

We're lacking the authority and delegation model that DNS has, I think?

If one were to ignore layer 9 politics, it could be argued the authority/delegation models between DNS and address space are quite analogous.

TODAY IANA has an operational role in DNS, they don't have
an operational role in Internet routing.

Yep. IANA does indeed have a limited operational role in the DNS (in that currently IANA directly operates .int, ip6.arpa, urn.arpa, uri.arpa, and iris.arpa) and no direct operational role in routing.

Of course, the statement was about the authority and delegation model, not about operational roles.

This is certainly not layer
9, and most certainly the most fundamental change to the Internet
routing system that RPKI or similar systems would introduce.

Not sure it is 'the most fundamental change', but it is indeed a significant change. That's sort of the point: RPKI is designed to allow for validation which isn't possible now.

To be clear: IANA and RIRs allocate or assign address space
today, they don't control any routing on the Internet (and their
own internal ASNs and IPs don't count).

Indeed. And if RPKI is deployed in a way that is useful for validation of routing announcements in real time, this will obviously change, regardless of whether there is a single root for the address space or multiple roots. However, it seems to me that the decision as to whether there is a single root or multiple roots is deeply rooted (pun intended) in layer 9.

But perhaps that's just me.

Regards,
-drc

39

OK, so we were talking past one another. I agree with everything
you said above, and simply meant to highlight the fact that RPKI
validation will change things (quite necessarily, IMO), and folks
need to be paying attention to this.

-danny

40

What I would like is to be able to filter prefixes on the basis of the AS-path/prefix combination, and have this in a signed fashion.

So let's say an ISP has AS1 and their upstreams are AS2 and AS3. They have 10.0.5.0/16.

They will then publish a routing policy that AS* (any AS) should only accept 10.0.5.0/16 originated from AS1, and no more specifics, but AS2 and AS3 should accept more specifics down to /24 (for granular traffic control). For this to be secure, I guess the announcement needs some kind of cryptographic verification, but I don't know much about that, but that should be used as well, but even without it we stop the possibility of human error announcing breakouts or that /16 by someone else.

Now, building existing prefix/AS-path lists based on the above information isn't feasable. We have ~30k ASN live and 270k prefixes so the amount of lines in a config is just unfeasable, which means we need some kind of new strategy to handle all this policy information. I guess having some kind of policy server which receives routes and then can tell routers to ignore them if they don't adhere to policy might work if the routes seen which is not according to policy are few, but if they become many then we run into the same scaling problem again.

So perhaps this problem can't be solved by anything existing, but instead we need new functionality in our routers to handle this problem? So time to market on this is in the years, but if we don't start work on it it'll never get done.

But I do feel that any long-term solution needs to be distributed and implemented on a per ASN basis, where participating ASNs doesn't have to be directly connected to each other...