Hi everyone,
I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that?
Thanks!
in an ideal world the ISP is filtering prefixes from their customer,
which means that the customer has to disclose downstream information.
so, yes. pleass tell your upstream your customers so proper filtering
can be automated and implemented.
don't turn up bgp customers without filtering, that kills kittens.
-chris
Um... you DO tell your provider the AS numbers of your customers... in
the BGP route announcement you send them. It's not a question of
rights or requirements. You already do it. Because that's how the
technology works.
As Chris noted, telling your provider out-of-band before sending the
same information via BGP is also a very good idea which enhances the
security of the whole doggone Internet.
Regards,
Bill Herrin
(Having been on both ends of this...)
If you want me to carry their traffic, yes, I need to know their address block(s) AND the ASN appearing behind yours. I will, in turn, have to provide that to my upstream provider(s).
NOBODY should be blindly accepting routing information from ANYONE, EVER. That's how people appropriate address space.
--Ricky
For all the leaking I've seen in the last four weeks
(including a well-known operator that was involved in the
Youtube/Pakistan saga + other well-known global operators
that could be classified as "a reasonably large tier"),
we're still a long way away ensuring all customer prefixes
are filtered correctly at the inter-domain peering edge. A
loooooooong way away...
Mark.
The reality is that this is (still) happening.
Mark.
Thanks. In order to prevent route leaking, this imformation should be provided to providers.
but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private?
Thanks. In order to prevent route leaking, this
imformation should be provided to providers.
Route leaking is not only from customers-to-providers. It
can also be from providers-to-providers (and from peers-to-
peers).
The majority of leaks I've seen in the past have been
possible because some inter-provider links have not been
filtered correctly, i.e., they are providing (unknown)
transit where they would only be peering.
It is not uncommon to see more relaxed filtering between
providers/peers, e.g., AS_PATH-based only, max-prefix-based
only, e.t.c., but please don't send these out to anyone else
besides your customers unless the ultimate relationship
calls for it. Of course, one can't guarantee that the
customers you send this to won't leak it to their own
transit providers.
Bottom line, chasing route leaks can be a full time job.
but another question, should the AS relationships between
customer and its other neighbors (downstrem/peer/another
provider) be private?
What do you mean, in terms of how they connect or in terms
of the business relationship?
I don't think it matters either way. The common peering,
filtering and re-announcement rules apply.
Mark.
Thanks. In order to prevent route leaking, this imformation should be
provided to providers.but another question, should the AS relationships between customer and its
other neighbors (downstrem/peer/another provider) be private?
perhaps you should draw a little ascii art, I think you're asking:
DS1 - customer - you - isp
"can DS1's relationship to 'customer' be secret"
no. well, not if they want:
1) to use a public ASN
2) use ip space which isn't part of 'customer' aggregate
3) want to be reachable on the internet
It's safe to say that your goal as an ISP and a customer of an ISP, should be:
"Make sure that all of my routes and the routes of my customers and
their customers, that I'm expected to provide transit for, are in my
ISP's filters."
-chris
(and as someelse pointed out: "If they use BGP and expect global
reachabilty... then the information isn't private anyway.")
+----------+ +---------+
> provider1| |provider2|
+----------+ +---------+
^ ^
> >
+--------+ ++-------++ +----------+
>peer AS2+-----+ AS 1 +----+peer AS3 |
+--------+ +---------+ +----------+
^ ^
> >
+------------+ +-------------+
>customer AS4| |customer AS5 |
+------------+ +-------------+
um....
sorry, my question is:
the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule. But if AS1 do it, and the realtionship between AS1 and AS3 is invisible to provider1, how can provider1 detect this route leak without knowing the privacy?
In other words, could the business relationship between AS1 and AS3 be known to provider1/2?
Thanks.
Sky li
the AS relationship between AS1 and AS2/3 is peer, and
AS1 cannot announce routes from AS3 to provider1 by
rule.
Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in
general best practice filtering rules, unless transit is
requested.
But if AS1 do it, and the realtionship between AS1
and AS3 is invisible to provider1, how can provider1
detect this route leak without knowing the privacy?
Provider-1 wouldn't care whether it's a route leak or not.
In Provider-1's mind, Peer-AS3 could (suddenly) be a
customer of AS1. And since AS1 is a customer of Provider-1,
Provider-1 will be happy to move those packets along as it
represents more revenue for Provider-1 (more so if traffic
is sold on a 95th percentile or volume utilization basis).
It is, really, up to AS3 to detect that AS1 has leaked its
routes (or paths, to be precise) to Provider-1, and then
pick up the phone and scream at AS1 to get that leak fixed
plugged.
Of course, all of this is a moot point if Provider-1 is a
good provider and makes sure they only accept routes and
paths from AS3 that AS3 should be sending to Provider-1 in
the first place. But as we know, some providers are a bit
(actually, very) lazy here.
In other words, could the business relationship between
AS1 and AS3 be known to provider1/2?
Not really (or not that easily, to be specific).
With enough time and access to several looking glasses and
public route servers, one could "infer" (to a certain degree
of error) business relationships between peering
relationships, i.e., whether they relationships are
customer, peer or provider.
But in your particular case, unless AS3 has a direct
connection toward Provider-1/2 (where a route leak would
introduce more problems), Provider-1/2 don't really care
about whether this is a leak or not from AS1.
But again, this whole discussion is mooted if Provider-1/2
do proper background checks and filtering before they turn-
up the service for AS1.
Mark.
Thanks. I'm doing some research on route leaks, you are a great help to me.
Sky li