In a properly functioning system - folks that consume the service don't need to know which node they are utilizing.
Right, it doesn't matter IF things are functioning properly. If they're not, however...
Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes?
This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today.
As for attack surface expanse, no. You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing.
In a properly functioning system - folks that consume the service don't need to know which node they are utilizing.
Right, it doesn't matter IF things are functioning properly. If they're not, however...
IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes?
This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today.
...but it *is* expressly about selection of nodes...
"Furthermore, control plane discriminators should exist to enable operators to know toward which
of a given set of instances a query is being directed, and to enable
detection and alerting capabilities when this changes. Such
discriminators may also be employed to enable anycast node preference
or filtering keys, should local operational policy require it."
As for attack surface expanse, no. You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing.
IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
Hehh.. As you well know, there are many folks that invest
enormous time and money into this, and yet realize, that ultimately,
there are influencers in the routing system and data path between
the client and the service node that the service operators can't
control. All they can do is best enable service consumers to
identify and incorporate controls that are optimal for their operating
environments.
...but it *is* expressly about selection of nodes...
It enables visibility and transparency which can be employed to
inform measurement and detection systems. IF / how an operator
chooses to apply controls based on that information (e.g., drop
a prefix originated from an unauthorized origin AS or leaked via
a known bad path) that's certainly their prerogative.
I manually extracted the origins and their org info for the announced
block of prefixes. All these prefixes were observed being originated
by at most four ASNs simultaneously. I suspect they provide anycast or
IXP service, but not positive. Please confirm my conjecture if you
know them.
We're using these IXP prefixes and they are very helpful, but I'm
afraid they are not complete. For example, I couldn't find any IXP
prefix from the mainland of China, such as Beijing and Shanghai.
Perhaps I'm misunderstanding the original question, but the assertion
that anybody is hijacking that particular prefix seems false.
Furthermore, that exchange prefixes may often appear to be anycast is
not unusual. Those prefixes are often originated by multiple disparate
networks who are connected to the exchange.
You mean that many different exchange points are using the same set of
prefixes as anycast service in different physical locations?
That sounds interesting to me.
No, just that you see route announcements for the exchange prefix
coming from multiple different origins and paths. So it may appear to
be anycast, but in reality would function as if it were multihomed with
the route originating from multiple providers. Additionally
reachability to addresses within the prefix may differ as a result of
the peering relationships from the perspective of the path taken to get
there.
in that period, it was originated by these parties, most of whom were authorized to
announce it. at this time, only one ASN is authorized to announce, and its not.
not sure how you expect to determine, with simple routing data, if the prefix was
hijacked. you would need to see the letters of authorization or contracts of service/carriage
to determine if an ASN was impropperly announcing.
for that matter, why do you care what occured years ago? the Internet is an evolving, fluid media
and things change all the time. if you want particulars on this prefix, i should have the
authoritative data, since I was the registered contact for both the prefix and the ASN in that
period and can pull the records. Contact me offline for details on access.
hum... from the service operator perspective, it seems that the operating mode is to reduce latency
for the requesting client. from the client perspective, latency may not be the most important thing
too bad the anycast fabrics only take the needs of the service operator into account...
>
>> Perhaps I'm misunderstanding the original question, but the assertion
>> that anybody is hijacking that particular prefix seems false.
>
> Furthermore, that exchange prefixes may often appear to be anycast is
> not unusual. Those prefixes are often originated by multiple disparate
> networks who are connected to the exchange.
You mean that many different exchange points are using the same set of
prefixes as anycast service in different physical locations?
That sounds interesting to me.
that has been a fairly common practice for nearly 15 years.
It's perhaps worth noting that there is work in the IETF to
recommend that every prefix originated as part of an anycast cloud
uses a unique origin AS (see
<http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>\). I'm
not personally convinced of the arguments in the draft, but
mentioning it in this thread seems reasonable.
I'm also not convinced of the arguments in the draft, since it argues
that it would be a best-practice
'A', not 'the', for the reasons conveyed in the draft (e.g., control
plane discriminator, RPKI foundations, etc..).
danny,
could you explain why this has anything to do with the rpki and origin
validation?
>
>
>>> 198.32.64.0/24
>>> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
>>> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
>>> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
>>> AS42909: as-name: COMMUNITYDNS;descr: Internet
>>> Computer Bureau Ltd
>>
>> according to Filip, this is -NOT- supposed to be
>> anycast. the only legal origin ASN is 4555.
>>
>> these other ASNs have hijacked the prefix.
>
> The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
This is based on last four year's data(2007-2010)collected from more
than 120 peers around the world. Today it may be not announced
anymore, but it used to be announced by the four ASNs simultaneously.
I just checked the detailed info about this prefix, here it is about
the prefix:
198.32.64.0/24
(ASN: average peers announcing this prefix:existing period:total
appearing days: MOAS period: total appearing days)
4555:4.94:20080318-20080506:50:20080318-20080506:50
9584:3.07:20080402-20080513:42:20080402-20080513:42
20144:79.44:20070101-20080501:487:20071215-20080501:138
42909:26.39:20071215-20080515:152:20071215-20080513:150
>
MY source data
> Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
>
This needs to do further analysis to confirm if it was hijacked
Yaoqing
>
> Joe
in that period, it was originated by these parties, most of whom were authorized to
announce it\. at this time, only one ASN is authorized to announce, and its not\.
not sure how you expect to determine, with simple routing data, if the prefix was
hijacked\. you would need to see the letters of authorization or contracts of service/carriage
to determine if an ASN was impropperly announcing\.
for that matter, why do you care what occured years ago? the Internet is an evolving, fluid media
and things change all the time\. if you want particulars on this prefix, i should have the
authoritative data, since I was the registered contact for both the prefix and the ASN in that
period and can pull the records\. Contact me offline for details on access\.
I might not explain the background clearly and confused people. We're
doing research on multiple origin AS issue, and we want to confirm if
our inference is correct based on history data we collected. For
example, we found several hundreds of prefixes with multiple origins
more than two, some of them were inferred as anycast using our
methodology, but we're not positive with the conjecture, so we want to
find the ground truth from operators. Thanks for the detailed
explanations.
I might not explain the background clearly and confused people. We're
doing research on multiple origin AS issue, and we want to confirm if
our inference is correct based on history data we collected. For
example, we found several hundreds of prefixes with multiple origins
more than two, some of them were inferred as anycast using our
methodology, but we're not positive with the conjecture, so we want to
find the ground truth from operators. Thanks for the detailed
explanations.
the ucla obsession with multiple-origin announcements has a long
history. the problem is that you think you can make something that
looks forward. but how will you decide if tomorrow's announcement of
P from A0 and A1 is anycast, ops kink, or an actual mis-announcement?
