Filter-based routing table management (was: Re: minimum IPv6 announcement size)
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots. As it is, we have no real feedback mechanism in the present system, just conventions that are variably enforced depending on relative stature of the parties having the discussion. Externalizing the true cost of having a prefix routed would create a more equitable and fair environment (i.e. knowledge that you could have any prefix globally routed for a fairly predictable cost, and ability to weigh the benefits of that versus taking a prefix from your ISP.) It might even spur research into various interesting alternatives such routing costs for smaller scopes (regional, geographic, etc.) and cost implications and technical tradeoffs from various alternative mobility schemes. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal & competitive aspects. However, it would at least be doing something more than crossing our fingers and just hoping for the best out of today's "IPv6 prefixes for all"... Another benefit of such a system (for those fans of market-based approaches) is that we could better utilize IPv4, rather than the currently implied "/24 is routable, /25 is not" filter-based approach which may not survive the market pressures associated with IPv4 depletion in any case... FYI, /John Disclaimer: My views alone. Feel free to ignore this message as desired.
On Thu, Sep 26, 2013 at 11:07 AM, John Curran <jcurran@istaff.org> wrote:
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal & competitive aspects.
From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in
Hi John, That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard: 1. The International Clearinghouse Every BGP participant files with a clearinghouse, specifying: a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network. Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity. The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out. The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters. the organization. A couple billion dollars per year if the routing table maintained its current size. 2. The partial routing scenario Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser. For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation. 3. The routing overlay Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress. The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table. Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination. Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
y'know, it's funny. there is a market in ipv4 space. there is no market in routing table slots. perhaps this is not conspiracy but rather the market is speaking. of course, we can use the idea of a market in routing table slots, rack space, or coffee to distract from the artificial problems in the only actual market, ipv4 address space. randy
On Sep 26, 2013, at 1:43 PM, Randy Bush <randy@psg.com> wrote:
y'know, it's funny. there is a market in ipv4 space. there is no market in routing table slots. perhaps this is not conspiracy but rather the market is speaking.
That easily could be the case. So how well is has the current model been working out for IPv4? It appears that only feedback mechanism is the "The Cidr Report" <http://www.cidr-report.org/as2.0/#Gains>, and last time this topic came up was almost exactly two years ago back at 375000 routes... is this success? Perhaps more conference banners are needed?
of course, we can use the idea of a market in routing table slots, rack space, or coffee to distract from the artificial problems in the only actual market, ipv4 address space.
No desire at all to distract from the discussions on that topic, and in fact, I'd encourage folks (including yourself) to pop on over to PPML and make suggestions for policy changes as desired. That's not an option available to me, and I was simply commenting on the fact that we're recreating the same IPv6 routing table feedback system which gave us our present "success" with the IPv4 routing table. FYI, /John
Oh this sure will be fun. For a good time, see how GSMA handles connectivity with IPXs. On Sep 26, 2013 1:28 PM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Sep 26, 2013 at 11:07 AM, John Curran <jcurran@istaff.org> wrote:
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal & competitive aspects.
Hi John,
That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard:
1. The International Clearinghouse
Every BGP participant files with a clearinghouse, specifying:
a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network.
Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity.
The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out.
The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters.
From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in the organization. A couple billion dollars per year if the routing table maintained its current size.
2. The partial routing scenario
Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser.
For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route.
With the routing costs suitably reduced, settlement for the remaining routes becomes moot.
This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation.
3. The routing overlay
Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress.
The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table.
Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination.
Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them.
With the routing costs suitably reduced, settlement for the remaining routes becomes moot.
The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Sep 26, 2013 at 5:05 PM, Scott Brim <scott.brim@gmail.com> wrote:
Oh this sure will be fun. For a good time, see how GSMA handles connectivity with IPXs.
Hi Scott, For those of us who aren't deeply engrossed in GSM mobile telecom, would you offer a synopsis? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Sep 26, 2013, at 11:07 AM, John Curran <jcurran@istaff.org> wrote:
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots.
https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997. We even had a BoF at an IETF, but you can imagine the reaction it got. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Yes, I was lazy in most of the adaptation, but I think it serves a good starting point for market based suggestions to the route slot problem. Your post advocates a (X) technical ( ) legislative (X) market-based ( ) vigilante approach to fighting spam^H^H^H^H route deaggregation. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) (X) No one will be able to find the guy or collect the money (X) End Users will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it (X) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once ( ) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it (X) Lack of centrally controlling authority for routing ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats (X) Jurisdictional problems (X) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP^H^H^H^H BGP ( ) Susceptibility of protocols other than SMTP^H^H^H^H BGP to attack (X) Eternal arms race involved in all filtering approaches (X) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers (X) Dishonesty on the part of spammers themselves (X) Bandwidth costs that are unaffected by client filtering ( ) Outlook and the following philosophical objections may also apply: (X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable (X) SMTP headers^H^H^H^H^H^H^H Routing should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (X) Countermeasures must work if phased in gradually ( ) Sending email should be free (X) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: ( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down! -Blake On Sat, Sep 28, 2013 at 6:10 PM, Steven Bellovin <smb@cs.columbia.edu>wrote:
On Sep 26, 2013, at 11:07 AM, John Curran <jcurran@istaff.org> wrote:
On Sep 26, 2013, at 4:52 AM, bmanning@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
If there were ever were a need for an market/settlement model, it is with respect to routing table slots.
https://www.cs.columbia.edu/~smb/papers/piara/index.html, from 1997.
We even had a BoF at an IETF, but you can imagine the reaction it got.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
On Sep 29, 2013, at 12:49 AM, Blake Dunlap <ikiris@gmail.com> wrote:
Yes, I was lazy in most of the adaptation, but I think it serves a good starting point for market based suggestions to the route slot problem.
Your post advocates a
(X) technical ( ) legislative (X) market-based ( ) vigilante
approach to fighting spam^H^H^H^H route deaggregation. Your idea will not work. Here is why it won't work. ...
There's actually no new technology involved, and you're overlooking the fact that there already _is_ market operating when it comes to routing table slots - try asking your ISP if they'll accept and propagate more specifics and your answer is going based on imputed worth to them as a customer... you just have no visibility into their assessment of your value, nor any way to make the judgement yourself and pay accordingly. FYI, /John
participants (6)
-
Blake Dunlap -
John Curran -
Randy Bush -
Scott Brim -
Steven Bellovin -
William Herrin