Query: What policies do backbone providers use to determine IP ownership?

Mailman List Mirror (Read Only)
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I'm curious to what extent everyone is checking to determine
ownership of IP addresses when taking on new customers.

Lately, multi-homing has become a very hot topic for even the
smallest of providers. With that, customers are bringing along
their IP addresses from their previous providers. Are we
required, as providers, to determine if that block is actually
owned by that customer, and facilitates good Internet routing?

I've seen a trend lately where I'm finding out, after the fact,
where pieces of larger CIDR blocks are being taken apart by a
myriad of unaggregated routes. The other backbone providers
freely allowed an announcement of that non-portable space to the
Internet without regard to either the owning provider, or to
general Internet routing.

My concern is two fold:

  1) This contributes to terrible Internet routing. By not
addressing this with the customer right away, we'll continue
to deal with a proliferation of /24s and Internet bloat. I
realize the customer needs its address space to announce
separately, but should we allow them to freely announce random
/24's? This is only due to that the customer received IPs by
growing over the years, rather than getting a single block up
front.

  2) It seems that other providers are allowing our customers to
hijack our routing space piece by piece. I will happily
participate in multihoming a customer, but I would hope it
involves us. We can make a contiguous allocation from our CIDR
blocks, and then work with the customer in a more consistent
manner. Much of this is customer education about multihoming,
but unfortunately we often find out too late.

So the question becomes, what do providers do to determine where
a block is coming from, and what is its implications on the
global routing system? Just cutting and pasting an email from
the customer into an access-list seems to be what we have now...

I'd be interested to hear what others thoughts and experience are
with this. Perhaps I'm just overly concerned with a normal
happening on the Internet.

Comments?

Tony

2

Customers want to be able to multihome. This is not an unreasonable desire,
and it is what they are, ostensibly, paying us for.

Your main complaint seems to be advertisement of individual netblocks from
larger aggregates. While this does contribute to the growth of the internet
routing table, this is an artifact of the way routing processes and BGP
work, rather than any fault from your customers. What are your customer's
options for multihoming?

1) Advertise smaller blocks out of larger aggregates to other providers
2) Get their own, PI space, and advertise it - if they are large enough to
obtain it. Of course, this causes one or more additional route announcements
as well.
3) The customer sucks it up, and sticks with a single provider

Clearly, most customers are going with #1 or #2, which will increase the
size of the routing table. They can minimize this by renumbering into
consecutive address space, but that assumes that this greatly disrupt their
business, and that they can indeed get a quantity of consecutive space from
an upstream.

"It seems that other providers are allowing our customers to hijack our
routing space piece by piece."

Is your complaint that other providers aren't calling you to get permission
to route your space? Although there may be some disagreement on the
etiquette of routing other provider's blocks, if someone has a block swip'ed
to them, that's pretty much license to route that block through a secondary
provider, unless the policy of the original provider specifically forbids
it. And in that case, the duty is on the customer to know his provider's
policies, rather than on the second provider to somehow research the
policies of the first provider. Of course, in the absence of affirmative
WHOIS information stating that a customer has the right to advertise a
block, it's wise to get written permission from the "owner of the block".

The routing table will increase in size, as the number of issued AS numbers
go up, as multihoming increases, as new address space is advertised.
However, current core router hardware is more than capable of dealing with
this growth. I certainly encourage customers to aggregate wherever possible.
However, requiring renumbering is a heavy, and unnecessary burden.

Multihoming has become part of basic transit service functionality.

- Daniel Golding

Tony Mumm Said....

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I certainly agree with your statements that customers want to
multihome, and that we will have to accommodate them. It is
quite reasonable, and we encourage it where high availability is
required.

I will also accept that renumbering can be a great amount of work
for a customer. I think that amount of work, however, is quite
justified if the customer has received portable space from the
registrar. I think the customer would be just as motivated to
get out of ISP provided IP space...just to be flexible the day
they decide to add/drop a provider.

On the technical front, with routers being what they are, I can
see that we are not in danger of hurting core routers with bloat.
Well, most of us anyway...I know of small shops that have had to
swap for more memory, etc as the table grew. I can now say that
their method of multihoming is the whole reason they need to buy
a new router (just kidding).

Secondary to that however, is that if I don't know what's
happening with the customer, how can we set this up correctly.
If no BGP peering session exists for that customer, they will
announce their smaller block as the only path, until its
withdrawn and only the CIDR remains. This is where I feel the
word hijacking applies. We would work with them to set it up
correctly so an AS path for this smaller block is passed through
us as well as the other customer.

I guess it comes down to etiquette in the end. If I whois the
block, and its non-portable space allocated to someone, I feel
they should know I'm going to announce it. This may have
technical repercussions on their network that they may want to
know about.

Customer education about the policies of the ISP who allocates
the IP space certainly will help I think, however customers
(bless their soul) will often do what suits them best regardless
of policies. Knowing the policy is probably the only way to
have reproach if a problem situation comes up.

The only check and balance in this whole process is the person
that is adding the route to their accept policies. It seems a
small inconvenience to check with the owning provider, and a
great courtesy to both ISPs.

In the end, communication will not only benefit the ISP, but also
the customer in the form of better routing (and understanding).

- -----Original Message-----

4

Here's a related question. Suppose provider A has a customer C who
multihomes with a connection to A and provider B. C uses IP's assigned by
A. C terminates service with A...but keeps announcing A's space to B. B
propogates the routes to their peers. B and C ignore requests that they
stop using A's space and renumber into B's. How does A reclaim their
space?

One obvious solution is dueling routes...A could announce more specific
routes, fouling things up for B and C hoping this will serve as
encouragement for C to renumber.

5

I have seen dueling routes more often than I'd like to recall.

No one wants to use space that isn't 100% routable. Assuming A has any
peers, some traffic will go there and dead-end. Any customer in the block
will be unhappy. B will eventually give up. A would be foolish to assign
customers in the block until B has given up.

If A is a much better connected network than B (since B is acting like an
ass) the process is much more definitive.

C can, and should be ignored.

Just my opinion, I could be wrong.

Deepak Jain
AiNET

jlewis@lewis.org

6

And then C could announce more specific routes, and so forth, although
you'll run into filters and start being ignored at some point.

That's really the sort of problem better resolved by lawyers than
by engineers.

-Steve

7

Why go through all that mess? You call up their new upstream, say
you're a representative of XYZ, and customer ABC does not have
permission to announce your netblocks. I know InterNAP requires
that they get consent from the netblock contact, I don't know about
other companies.

And so it doesn't happen as a prank, while on phone with them, tell
the person to send an e-mail to the netblock contact, you open up the
e-mail and read it back to them for verification, it seriously can't
be that complicated. kthkxbye.