August 2008 - Test - lists.nanog.org

Coin Op Peering Fabric?
by Rick'n Fidiot 13 Aug '08

13 Aug '08

Warning: This may actually be operational too. Given Cogent's (and others) recent pursuit of sub $4/mb/s transit (at least as far as all the bottom feeders and gossippers like to talk about) and the relatively flat cost of a "paid" peering fabric (even on IP8) and the fancy non euclidean name dropping formula costs for cross-connects, the thought of revising current packetized switching model into the historical pay phone model presents itself again. Assuming the Clos switch fabric model, if we simply repudiate all self-evident rights of capitalist business people to compete in a fair market, we should again return to the days of government subsidized monopolies and absolved self-responsibility to avoid the perils of anti-randian unfair competition and a technologically advanced race to the bottom. A "coin-op" best-effort pay as you go switching fabric would be in everyone's best interest (read FAIR and anti-bourgeois classism), and a community designed Clos switch would present no more than 30% blockage on non-peak hours. In this model, people who can't succeed at business could go off and talk about Spam all day, and in their free time they could move cross-connects around, kind of like at the early digital non-NSF funded NAPs. The way I figure it, this would provide a living wage for network engineers that spend all day arguing abstract points in email. You'd simply deposit an American Nickel into the Hawala Peering system. Does this actually improve the quality of the network experience? I dunno. Warning: This may actually have more Merit than other recent posts and the hosting organization of this public discussion list. Yours in contemplation, (f)Rick N. Idiot

1 0

Coop Peering Fabric??
by Deepak Jain 12 Aug '08

12 Aug '08

Warning: This may actually be operational too. Given Cogent (and others) recent pursuit of sub $4/mb/s transit... and the relatively flat cost of a "paid" peering fabric (even at 10G) and the O(N) costs for cross-connects, the thought of revisiting the old peering coops presented itself again. Assuming 10G PNI model: Assuming even nominal cross-connect fees of $100-$300/month per fiber pair, plus router port costs for each private peer (assuming you aren't at >10% utilization on the port) at a commercial exchange, you are eating a pretty significant cost per megabit you are actually moving. (plug in your numbers here). Assumption: Above 1Gb/s utilization, this makes sense or you are counting on growth. Below 10% you would normally go to a paid peering fabric where you are paying cross connect + a flat port charge + router port for 1->N peers and hoping that enough utilization occurs that you get >10% utilization (to recover capex, opex, etc) and then whatever additional utilization you need to cover the flat port charge or you are counting on growth. A "coop", best-effort switch fabric colo'd at a few sites would allow participants to peer off traffic at a price of the order of a single cross-connect (~$500/month per 10G port is possible, maybe less), private-VLANs all-around, or to only-mutually approved peers (e.g. via an automated web interface, prior art) to avoid many of the /old/ issues. No requirement for multi-lateral peering. You could peer, sell transit, buy transit, multicast, etc. The way I figure it, it removes approximately an order of magnitude from the operational cost of peering with more than a handful of your largest single talkers. Especially as 100G LAN Ethernet becomes production before 100G WAN connections become commonplace. Economic theory (assuming that worked on the Internet) suggests this would allow for the increase in number of peers by approximately an order of magnitude (maybe more). Does this actually improve the present-day "rationale" to peer, or are most operations' costs so far above (from long haul, etc) or so far below (since the cost of transit has dropped so much) that this is no longer a relevant part of the equation? Warning: This may actually be operational too. Deepak Jain AiNET

19 34

BGP route filtering. You want it.
by Anton Kapela 12 Aug '08

12 Aug '08

List, [Apologies in advance for operational content. I Don't mean to distract readers from the usual flamewars about rfc1918, bogon filtering, and some of our favorite posters - gadi and n3td3v.] I'd like to give a heads-up to the NANOG community regarding the talk we recently gave at DEFCON. The slides can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt In a nutshell, we demonstrated that current lack of secure filtering infrastructure not only permits DoS-like attacks, but also full "traffic monitoring" of arbitrary prefixes from essentially anywhere in the world. None of this should come as surprise to the NANOG and operationally-aware crowd - this has been discussed extensively previously before on-list, and extensively at conferences. Additional novelty presented is the returning of traffic back to victim network over Internet (creative as-path prepends & loop detection) and obscuring the 'additional hops' this sort of thing creates with additive ttl. Suggested additional reading below: http://www.nanog.org/mtg-9802/yu.ppt http://www.nanog.org/mtg-0010/ppt/tony.ppt http://www.nanog.org/mtg-0010/ppt/danny.ppt http://www.nanog.org/mtg-0206/ppt/security1.1.pdf http://www.nanog.org/mtg-0501/pdf/tauber.pdf http://www.nanog.org/mtg-0505/pdf/underwood.pdf http://www.nanog.org/mtg-0510/pdf/deleskie.pdf http://www.nanog.org/mtg-0602/pdf/boothe.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/massey.pdf http://www.nanog.org/mtg-0806/presentations/wednesday/DanMcP_Route_Filter_P… http://www.nanog.org/mtg-0806/presentations/sunday/BRGREEN_prefix_filtering… http://www.renesys.com/tech/presentations/pdf/menog3-youtube.pdf http://www.renesys.com/tech/presentations/pdf/nanog43-hijack.pdf -Tk/P.

2 2

Coop Exchange
by Donald J Westlight 12 Aug '08

12 Aug '08

The main argument for an exchange is qualitative. Do you want your bits to get where they are going with low latency, jitter, and packet loss? Exchanges are a very practical way to solve the N squared peering problem. Speaking as a founder of a small exchange; it does all come down to money. Quality hardware is expensive, and combining this with the OPEX for co-lo/power, etc. starts to get a bill on the order of $500/mo/gigE port. In my experience, the larger the company, the less likely they will be willing to pay anything to support a shared peering fabric (at least in my market.) Our membership tends to be regional players who are used to cooperating already, and together start to approximate the capability of one of the big carriers. Exchange membership also jumpstarts business with larger carriers when they arrive. I just toured the SIX last month, and I’m really impressed by their operation. Everybody has costs. I am particularly interested in what NANOG would consider fair, and on top of that whether or not a quorum would actually pay. I am particularly concerned that the "race to the bottom" describes cost and quality, as well as limitation of new application development and deployment... If you guys have a blueprint for a community or coop exchange that you'd subscribe to, I strongly suspect that it would happen. I'm happy to talk more about this off list with anybody interested. Don Westlight NWAX.NET, est 2001 Portland Oregon 921 SW Washington 22 Members 1.3gb daily max westligh(a)ohsu.edu

1 0

Comcast Tech?
by Alex Rubenstein 12 Aug '08

12 Aug '08

I am looking for a Comcast tech to help us solve what may be a simple issue. Normal channels have failed. Find me at alex(a)nac.net please .. thanks!

1 0

[NANOG-announce] Call for Nominations for NANOG Steering Committee 2008/9
by Philip Smith 12 Aug '08

12 Aug '08

Hello everyone, Elections for three of the six elected positions on the NANOG Steering Committee will be held in October 2008. The currently-serving Steering Committee members whose terms are expiring are Joe Provo, Randy Bush and Philip Smith. Randy and Philip have also served two consecutive terms so, as per the charter, they cannot be considered for re-election until October 2009. The NANOG Steering Committee works closely with Merit to promote, support and improve NANOG. The Steering Committee is responsible for the selection of the Program Committee and the Mailing List Committee, and is the community's instrument for ensuring that NANOG as an organisation remains open, relevant and useful. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being an Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/charter.html http://www.nanog.org/sc.current.html HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations(a)nanog.org. The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG44 Community Meeting, Sunday, October 12th, beginning at 5:30 PM, PDT. IMPORTANT DATES Tue 2008-08-12 Call for Nominations issued Tue 2008-09-09 Last day for SC Nominations to be received Sun 2008-10-12 Voting for the 2008/2008 NANOG SC opens at Noon PDT Tue 2008-10-14 Voting for the 2008/2009 NANOG SC closes at 1 pm PDT Results will be announced at the close of the meeting Philip Smith (on behalf of the NANOG Steering Committee) -- _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: BGP route filtering. You want it.
by Bourbon.Odenthal＠sce.com 11 Aug '08

11 Aug '08

I really enjoyed it! Rerouting all of Defcon's traffic thru NY was a nice touch. Hopefully the additional awareness of this will help progress toward getting the issues fixed. Good job! -bb ----- Original Message ----- From: "Anton Kapela" [tkapela(a)gmail.com] Sent: 08/11/2008 01:47 PM MST To: nanog(a)nanog.org Subject: BGP route filtering. You want it. List, [Apologies in advance for operational content. I Don't mean to distract readers from the usual flamewars about rfc1918, bogon filtering, and some of our favorite posters - gadi and n3td3v.] I'd like to give a heads-up to the NANOG community regarding the talk we recently gave at DEFCON. The slides can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt In a nutshell, we demonstrated that current lack of secure filtering infrastructure not only permits DoS-like attacks, but also full "traffic monitoring" of arbitrary prefixes from essentially anywhere in the world. None of this should come as surprise to the NANOG and operationally-aware crowd - this has been discussed extensively previously before on-list, and extensively at conferences. Additional novelty presented is the returning of traffic back to victim network over Internet (creative as-path prepends & loop detection) and obscuring the 'additional hops' this sort of thing creates with additive ttl. Suggested additional reading below: http://www.nanog.org/mtg-9802/yu.ppt http://www.nanog.org/mtg-0010/ppt/tony.ppt http://www.nanog.org/mtg-0010/ppt/danny.ppt http://www.nanog.org/mtg-0206/ppt/security1.1.pdf http://www.nanog.org/mtg-0501/pdf/tauber.pdf http://www.nanog.org/mtg-0505/pdf/underwood.pdf http://www.nanog.org/mtg-0510/pdf/deleskie.pdf http://www.nanog.org/mtg-0602/pdf/boothe.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/massey.pdf http://www.nanog.org/mtg-0806/presentations/wednesday/DanMcP_Route_Filter_P… http://www.nanog.org/mtg-0806/presentations/sunday/BRGREEN_prefix_filtering… http://www.renesys.com/tech/presentations/pdf/menog3-youtube.pdf http://www.renesys.com/tech/presentations/pdf/nanog43-hijack.pdf -Tk/P.

1 0

Why *can* cached DNS replies be overwritten?
by Jay R. Ashworth 11 Aug '08

11 Aug '08

On Mon, Aug 11, 2008 at 11:20:07AM -0400, Leo Bicknell wrote: > If your vendor told you that you are not at risk they are wrong, > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > the only question is if the attack takes 1 second, 1 minute, 1 hour > or 1 day. While possibly interesting for short term problem > management none of those are long term fixes. I'm not sure your > customers care when .COM is poisoned if it took the attacker 1 > second or 1 day. Correct me if I'm wrong, Leo, but your assertion turns on the fact that the server will accept an overwriting cache entry for something it already has cacheed, does it not? Do djb and Power in fact do that? If they don't, the window of opportunity to poison something like .com is limited to the period between when that entry expires from the local server's cache and the next time it hears a reply -- which will be the time after that expiry when someone next requests a .com name; IE almost immediately, no? Everyone seems to continue asking "why can poisoning overwrite already cached answer" and no one seems to be answering, and, unless I'm a moron (which is not impossible), that's the crux of this issue. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

5 5

DNS attacks evolve
by Joe Greco 11 Aug '08

11 Aug '08

It's usually interesting to be proven wrong, but perhaps not in this case. I was among the first to point out that the 11-second DNS poisioning claim made by Vixie only worked out to about a week of concentrated attack after the patch. This was a number I extrapolated purely from Paul's 11-second number and the factor-of-65000x introduced by port randomization. I am very, very, very disheartened to be shown to be wrong. As if 8 days wasn't bad enough, a concentrated attack has been shown to be effective in 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html With modern data rates being what they are, I believe that this is still a severe operational hazard, and would like to suggest a discussion of further mitigation strategies. On my list of concepts: 1) Use of multiple IP addresses for queries (reduce success rate somewhat) 2) Rate-limiting of query traffic, since I really doubt many sites actually have recursers that need to be able to spike to many times their normal traffic, 3) Forwarding of failed queries (which I believe BIND doesn't currently allow) to a "backup" server (which would seem to be interesting in combination with 2) 4) I wonder if it wouldn't make sense to change the advice for large-scale recursers to run multiple instances of BIND, internally distribute the requests (random pf/ipfw load balancing) to present a version of 1) that would render smaller segments of the user base vulnerable in the event of success. It would represent more memory, more CPU, and more requests, but a smaller victory for attackers. 5) Modify BIND to report mismatch QID's. Not a log report per hit, but some reasonable strategy. Make the default installation instructions include a script to scan for these - often - and mail hostmaster. 6) Have someone explain to me the reasoning behind allowing the corruption of in-cache data, even if the data would otherwise be in-baliwick. I'm not sure I quite get why this has to be. It would seem to me to be safer to discard the data. (Does not eliminate the problem, but would seem to me to reduce it) 7) Have someone explain to me the repeated claims I've seen that djbdns and Nominum's server are not vulnerable to this, and why that is. It would seem that the floor is wide open to a large number of possibilities for mitigating this beyond the patch. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

6 6

Solution vs. Implementation
by Bruuce Williams 11 Aug '08

11 Aug '08

Could someone who reads "the other lists" on the DNS problem mind posting a summery here? While this list is theorizing a solution, they may be theorizing implementation considerations, so a little back-and-forth communication might be useful. Just a thought... Bruce Williams the first principle is that you must not fool yourself, and you are the easiest person to fool -- Richard P. Feynman

1 0