[Nanog-futures] 2008 NANOG charter amendments
It's that time of year again, folks, when we get to work on a batch of charter amendment proposals for the October ballot. Suggestions so far are at: http://www.nanog.org/charter/ Rob Seastrom has volunteered to be our community charter wrangler this year, and will be helping to lead discussion on this list and keep the web versions current. If you have comments on the proposals, or suggestions for other amendments, please discuss them on this list or contact Rob directly at [EMAIL PROTECTED] You can also contact me and/or any of the other SC member(s) if you have any concerns. Steve (for the Steering Committee) ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Teleglobe appears to be spam-source zombie network?
On Sep 10, 2008, at 6:50 PM, Yann Berthier wrote: while there is certainly outdated abuse info for some of our blocks, in this particular case the subnet that was allocated to us has up-to-date mail+phone info I'd like to note for anyone else who might make similar mistakes -- putting valid contact info only in the top level allocation and not tied to your organization means that nobody can find it, unless they are bored and feel like trying the IP with /25, /24, /23, /22 ... etc until they find your working contact info. Do it right, tie the abuse contact to the organization. It will show up on *all* allocations. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Teleglobe appears to be spam-source zombie network?
On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: It's possible that in the shuffle of company renaming/rebranding/rejiggering-of-people they lost this bit in the Is it just me, or isn't keeping valid contact information on your netblocks like, a serious affair? Something you should get around to within a few hours, nevermind a few months since the changes? I mean seriously. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Teleglobe appears to be spam-source zombie network?
On 9/11/08, Jo Rhett [EMAIL PROTECTED] wrote: On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: It's possible that in the shuffle of company renaming/rebranding/rejiggering-of-people they lost this bit in the Is it just me, or isn't keeping valid contact information on your netblocks like, a serious affair? Something you should get around to within a few hours, nevermind a few months since the changes? I mean seriously. Depends on if you take it seriously to begin with, as well as if the next person after you leave takes it seriously. I left an org over a year and a half ago, and the abuse/tech contact info for the netblocks has yet to be updated. YMMV. -brandon
Re: an effect of ignoring BCP38
On Sep 6, 2008, at 6:49 AM, k claffy wrote: do that many networks really allow spoofing? i used to think so, based on hearsay, but rob beverly's http://spoofer.csail.mit.edu/summary.php suggests things are a lot better than they used to be, arbor's last survey echos same. are rob's numbers inconsistent with numbers anyone else believes to be true? I hate to spoil anyone's fantasies about this topic, but yeah. Nearly everyone does. I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments) If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed. We don't have a long ways to finish. We have a long ways to start. Finishing isn't even within the horizon yet. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: BCP38 dismissal
On Sep 4, 2008, at 3:22 PM, Gadi Evron wrote: On that you'll have to speak for yourself. We have it on every customer port ;-) Now that is interesting. Can you share a bit about you rimplementation hardships, costs, customer complaints, etc? One customer complaint. Found the customer was looping traffic between two uplinks and helped them fix the problem ;-) Implementation cost: time/labor to implement automatic management of ACLs on the customer ports. Not all that much cost, since we had already developed infrastructure to do the same thing for customer configurations. Maybe 12 hours of my time coding and testing. Honestly, I expected a lot more problems than we've had. Especially given the fallout I'd seen on the networks trying to do it with Cisco. But the Force10 gear didn't even notice the effect, and it's been ~2 years since I've even thought much about it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Force10 Gear - Opinions
On Sep 5, 2008, at 12:37 PM, Paul Wall wrote: Jo Rhett wrote: Note the not random comment. People love to use the random feature of ixia/etc but it rarely displays actual performance in a production network. Once upon a time, vendors released products which relied on CPU-based flow setup. Certain vintages of Cisco, Extreme, Foundry, Riverstone, etc come to mind. These could forward at line rate under normal conditions. Sufficient randomization on the sources and/or destinations (DDoS, Windows worm, portscans, ...) and they'd die a spectacular death. Nowadays, this is less of a concern, as the ... Either way, I think it's a good test metric. I'd be interested in hearing of why you think that's not the case. Back on topic, doing a Yes. And those problems were fixed in most gear. What I found *also* was that the flow tables tended to fill up, and a lot of gear thrashes on the flow tables. You need real bi-directional sessions to create the effect properly in many cases. (ie Extreme, which handles random fine but bidirectional flows proved that too much of the work was being done in software) I have a current spreadsheet here, and trust me your math went wrong somewhere. A completely full chassis is only a bit more than what you are ... But no, I'm not going to redo the math. I'm not a F10 salesperson and I have much more important things to do right now. I'd be interested in seeing where I went wrong, in the interest of setting the record straight. The original poster was interested in how Force 10 stacks up against the competition from a feature and price prospective. He deserves some cold science, and I'm trying to help him out. I meant what I said, and I wasn't trying to be rude. There are F10 people on this mailing list, it would serve you to engage them instead of me. I'm quite happy with my Force10 units but I'm not making any commission selling them and I have too much to do to be doing someone else's job. To wit, you said F10 is cheaper than a comparable Cisco 6500 (in a basic gig-e configuration). I demonstrated that's not the case. You responded with ad-hominem attacks, followed by indifference, and later, claims of emotional distress; still you refuse to provide any hard numbers, claiming it's not your job. Where I come from, people like that are referred to as sore losers. :) You're reading a lot more into it than I bothered to think about it. I've done the math repeatedly, and Force10 always comes out cheaper than Cisco in that scale of port density. Your numbers looked off to me, but letting you know the previous sentence is about all the time I can spend on this topic. Can we kill this now? Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Cisco uRPF failures
On Sep 6, 2008, at 10:20 AM, Anton Kapela wrote: On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett [EMAIL PROTECTED] wrote: That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and What do you mean by 'non routable?' Should have been dropped by UDP. What was the src/dst makeup of the test traffic? Both random sources and singular sources demonstrated the problem. What version of code? Also, port-channel/lag or ECMP? I don't have those details handy now, nor am I likely to anytime soon. If they've been solved in recent code, great. But I've seen nothing in the tech notes. quickly, but that turns out not to be the case. To this day I've never I've never seen the issues you speak of, so it could be code/platform/config specific. Also, what sup were you testing? 720s, as said repeatedly. Forgive me, but what does bits/sec have to do with anything? The problem only appeared at high bits/sec, as I've said repeatedly. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: BCP38 dismissal
On Sep 7, 2008, at 12:18 AM, Randy Bush wrote: normally i would have just hit delete. but your ad hominem attack on the messenger need a response. the reality of life is that he is correct in that attack traffic comes from legitimate IP sources anyway. therefore, your first duty should be to keep your hosts from joining the massive army of botnets. Having no hosts, I can't do much about that other than use various good best practices (including BCP38), run ids units looking for compromised hosts, and respond quickly to each abuse report if my IDS doesn't observe it first. Given that I know of no provider larger than us using BCP38 on every port, and no other provider larger than us that responds to every abuse report, it would appear that we are top of the class in that aspect. Therefore, when someone says I don't need to do BCP38 because BCP38 doesn't cause problems for them, I consider them a jerk. And yeah, I feel pretty confident looking down my nose at someone like that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: BCP38 dismissal
normally i would have just hit delete. but your ad hominem attack on the messenger need a response. the reality of life is that he is correct in that attack traffic comes from legitimate IP sources anyway. therefore, your first duty should be to keep your hosts from joining the massive army of botnets. Having no hosts, I can't do much about that other than ... i suggest you go back to the mail to which you responded obscenely vilifying the poster who was specifically saying he worried about his host before bcp38. that was specifically the subject. Given that I know of no provider larger than us using BCP38 on every port well, that sets an upper bound on the extent of your knowledge, eh. and not a very high one. randy
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008, Jo Rhett wrote: I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments) If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed. A problem I have with these discussions is that everyone has their own idea what BCP38 implies. Others say their loose-mode uRPF setups are BCP38. Others are using strict uRPF or similar (e.g. acls). Some think that Tier1 transit operators should apply one of the options above to their tier2 customers. Others think it should just be applied at the site-edges. Some don't consider spoofing protection at LAN interface level at all, others call that also BCP38. Etc. Your note above seems to imply that you would expect the five best transit providers you think of to apply BCP38 (strict?) to their customers. Even if the customer is a major ISP? (However, if your argument is about a smallish end-site, I'd agree spoofing protection should be applied there.) FWIW, I've tested what would happen if I were to enable strict-mode (feasible paths) uRPF on an Internet exchange (all peerings). If I recall correctly, the amount of dropped packets would have been in the order of 1%. We decided not to do it. Maybe those five biggest providers you can think of have similar experiences with their biggest customers? Loose mode URPF is seems (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: an effect of ignoring BCP38
On Sep 11, 2008, at 12:59 AM, Pekka Savola wrote: A problem I have with these discussions is that everyone has their own idea what BCP38 implies. Others say their loose-mode uRPF setups are BCP38. Others are using strict uRPF or similar (e.g. acls). Some think that Tier1 transit operators should apply one of the options above to their tier2 customers. Others think it should just be applied at the site-edges. Some don't consider spoofing protection at LAN interface level at all, others call that also BCP38. Etc. Honestly, *anything* is better than most of what's out there, which is *nothing*. Loose mode URPF is seems (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing. I disagree. But I will say that if everyone would apply strict mode or ACLs to their end point interfaces, this would likely make most of the loose mode irrelevant. And your arguments about BGP changes affecting loose mode are only problematic on the busiest peering ports. Loose mode works perfectly fine with zero drops (even on Cisco) on anything smaller than a full feed (ie, that ISP client of yours you do BGP with) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: InterCage, Inc. (NOT Atrivo)
Gadi Evron wrote: On Mon, 8 Sep 2008, Scott Weeks wrote: --- [EMAIL PROTECTED] wrote: I am sure if I looked into it more I could find some exploits related to the sites. - Why software piracy might actually be good for companies. Folks should clean their own house before pointing fingers at others... My house may not be clean right now, but the cleaner is coming tomorrow. However, filth from their house is making my house smell. I am very happy they are willing to clean up, but it still smells for some reason. Enough with analogies, you are making this discussion into a hostile environment for them to reply in. What are you afraid of, anyway? Are you running a bullet-proof hosting farm? Why should an ISP provide proof of the good behavior of their clients ? Or in your conuntry you're considered guilty until proven otherwise ?
Re: InterCage, Inc. (NOT Atrivo)
Why should an ISP provide proof of the good behavior of their clients ? Or in your conuntry you're considered guilty until proven otherwise ? This is not a court. In court, if you are determined guilty a large punishment may be exacted (note: it's innocent until determined to be very likely guilty in criminal cases, innocent until probably guilty in civil cases); here, that is not the case. They have a history of abuse; it's fair to be suspicious of them (why did they let the abuse last so long?) and ask for an example of a legitimate client. If they have a few, it should be easy to find one willing to be used as an example.
Re: InterCage, Inc. (NOT Atrivo)
On Thu, September 11, 2008 10:58 am, Eugeniu Patrascu wrote: Why should an ISP provide proof of the good behavior of their clients ? Or in your conuntry you're considered guilty until proven otherwise ? Conversely, and sticking close to the 'clean house' metaphor, if someone has a history of tramping mud into your carpets every previous time they've visited, is it unreasonable to ask them to present clean shoes before letting them into your house again? Regards, Tim.
Re: ingress SMTP
Joel Jaeggli [EMAIL PROTECTED] writes: Does anyone bother to run an MSA on 587 and *not* require authentication? All my normal relay or lack thereof and delivery rules are in place on my 587 port. Of course muas's and mtas will also do tls as well as authentication over port 25 where available. I don't sea any reason to preclude a host that would be allowed to relay via 25 to do so via 587... Congruent policy makes administration simpler. Counterpoint here: I do not allow relaying (only local delivery and maybe MX but I think I'm not doing secondary MX for anyone anymore) over port 25 and I do not allow authentication over port 25 either. Likewise, I do not allow unauthenticated local delivery on port 587, demand STARTTLS on port 587, and generally you have to auth to do anything. The extra effort required to set this up (exim recipes available) pays dividends by ensuring that people have their MUAs configured properly at home - otherwise they won't work at all - and helps avoid whiney long distance phone calls asking for help from some user who's off in Bonaire or something. -r
RE: BCP38 dismissal
i suggest you go back to the mail to which you responded obscenely vilifying the poster who was specifically saying he worried about his host before bcp38. that was specifically the subject. host in that context was his router, which makes your comment make less sense. (having never seen a big iron router become a client in a botnet, myself) He was talking about big iron control plane policy controls. You must have missed the context. Actually, Randy is right. We were discussing in context of routers and botnets themselves. Host in my context was about the botnets sending attack from legitimate IP sources that BCP38 will not be able to defeat. You want to stop being rude, and start making positive assertations about things you know? I'd love to be wrong, but I've got a whole lot of experience on this topic. If you know better, educate the rest of us. No, you have demonstrated that the only jerk in this entire forum is no one but you with limited bounds of intelligence. Before you go on and call someone a jerk, idiot and falsely accuse him of ~not wanting to deploy BCP38[1]~, read your own posts and start making positive assertions about things that you know yourself. [1]: Almost every network that I help manage is operated with BCP38 either with uRPF or even with automatic-scripted SAV (source address verification/filtering)/ ACL's. james
Re: Teleglobe appears to be spam-source zombie network?
Randy Bush wrote: why don't we just have dick cheney bomb them? We could send in the Trojan Moose. Justin
Re: InterCage, Inc. (NOT Atrivo)
Lamar Owen wrote: Lack of a defense in a civil case will virtually guarantee a favorable judgment for the plaintiff, however. Networks (at least in most countries) are 100% private entities who can de-peer whoever they want for whatever reason they want.
Re: Teleglobe appears to be spam-source zombie network?
On Thu, Sep 11, 2008 at 3:18 AM, Jo Rhett [EMAIL PROTECTED] wrote: On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: It's possible that in the shuffle of company renaming/rebranding/rejiggering-of-people they lost this bit in the Is it just me, or isn't keeping valid contact information on your netblocks like, a serious affair? Something you should get around to within a few hours, nevermind a few months since the changes? That's not my arguement ;( the thing I noticed while at a telco is that sometimes they don't care about the intertubes :( the corporate masters have other priorities. It sucks, I was thinking that the teleglobe/vsnl/tata folks may have gotten bitten by a similar event. (and yes, having as up-to-date info as possible is important for your customers and your peers) -Chris
Re: an effect of ignoring BCP38
On Sep 11, 2008, at 6:32 AM, Pekka Savola wrote: FWIW, based on off-list discussion, Jo's disagreement seems to stem from a misunderstanding of how loose uRPF works (he didn't know it accepts any packet that has a route in the routing table). Um, no. Because if you put loose mode uRPF on your edges you aren't implementing BCP38 now are you? I don't care how it is deployed. That's your job ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008 00:28:25 PDT, Jo Rhett said: I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments) Part of the problem is that if you're talking about the 5 biggest providers, and the 5 biggest transit, you're talking about places with routing swamps big enough, and with sufficient dragons in residence, that you really *can't* do BCP38 in any sane manner. AS1312 (us) is able to do very strict BCP38 on a per-port level on every router port, because we *know* what's supposed to be on every subnet. By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed. The MIT Spoofer project seems to indicate that closer to 50% *of the edge* is doing sane filtering. And that's where you need to do it - *edge* not *core*. pgpOCStXrRojQ.pgp Description: PGP signature
Re: Cisco uRPF failures
On Sep 11, 2008, at 10:11 AM, Saku Ytti wrote: On (2008-09-11 00:50 -0700), Jo Rhett wrote: As someone who does a lot of work talking to NOCs trying to chase down attack sources, I can honestly tell you that I haven't talked to a single NOC in the last 16 months who had BCP38 on every port, or even on most of their ports. And the majority response is our (vendor) gear can't handle it. As we both know, Cisco is the largest by far vendor in the marketplace, and I've heard that name more than 70% of the time. Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does). I don't honestly know. I do know that in every case it was mentioned to me it was either a 6500 or a 7600. (that it was a Cisco anyway) But frankly, lack of uRPF doesn't mean that BCP38 is impossible. My generation of Force10 gear can't do uRPF. Yet we are BCP38 compliant. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Cisco uRPF failures
On (2008-09-11 00:50 -0700), Jo Rhett wrote: As someone who does a lot of work talking to NOCs trying to chase down attack sources, I can honestly tell you that I haven't talked to a single NOC in the last 16 months who had BCP38 on every port, or even on most of their ports. And the majority response is our (vendor) gear can't handle it. As we both know, Cisco is the largest by far vendor in the marketplace, and I've heard that name more than 70% of the time. Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does). -- ++ytti
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008, Jo Rhett wrote: On Sep 11, 2008, at 10:10 AM, [EMAIL PROTECTED] wrote: By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. This is where Strict URPF (+feasible paths) helps a lot because in some cases you don't need to manage those ACLs by hand. But this gets broken if the customer advertises more specific routes from another provider, but doesn't advertise these to you -- your route to those more specifics goes through another ISP, and if the site is sourcing packets from those more specifics through you, the strict uRPF would drop them. There are ways to work around this, e.g. by requiring that the customers advertise the more specifics to you as well but mark them so that you don't propagate them, but I suspect this is not feasible in the higher tiers of ISP business. http://tools.ietf.org/html/draft-savola-bcp84-urpf-experiences Section 3 discusses this a bit. FWIW: we use feasible-paths strict uRPF on all customer and LAN interface without exception. Multihomed ones as well, though it's a bit more work. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008 10:25:01 PDT, Jo Rhett said: I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. The problem isn't your customers, it's *their* customers who also multihome to somebody you peer with at 3 other locations. AS1312 talks to AS7066, which talks to AS1239, and we talk to AS40220, which talks to Level3 and AboveNet. Now - for each of your routers, what interfaces *can* or *can't* see legitimate packets from us? Does your answer change if something at MATP burps and loses its Lambdarail connection? *That* is the use case that makes it difficult-to-impossible for the 'top 5' to do anything resembling strict BCP38. pgphyIoSHmlaw.pgp Description: PGP signature
Re: an effect of ignoring BCP38
Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) From: Pekka Savola [EMAIL PROTECTED] On Thu, 11 Sep 2008, Jo Rhett wrote: On Sep 11, 2008, at 10:10 AM, [EMAIL PROTECTED] wrote: By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. It's big, but not un-workable. Just looking at our lists, the longest is over 212K entries and we have 5 over 5K and 20 over 1K. We would have even bigger ones if the IRR had more complete information. I'll admit that doing this for a tier-1 would probably not work, though I have never been able to try as the requisite information is not publicly available. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpttrkgVOh3t.pgp Description: PGP signature
Re: an effect of ignoring BCP38
Date: Thu, 11 Sep 2008 11:24:43 -0700 From: Kevin Oberman [EMAIL PROTECTED] Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) From: Pekka Savola [EMAIL PROTECTED] On Thu, 11 Sep 2008, Jo Rhett wrote: On Sep 11, 2008, at 10:10 AM, [EMAIL PROTECTED] wrote: By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. It's big, but not un-workable. Just looking at our lists, the longest is over 212K entries and we have 5 over 5K and 20 over 1K. We would have even bigger ones if the IRR had more complete information. Ack! Fat fingered it! Certainly not 212K entries. That was supposed to be 12K. Not nearly so impressive. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpjzdRgPSKYY.pgp Description: PGP signature
2nd CfP: ICNS 2009 | April 21-25, 2009 - Valencia, Spain
Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Apologies for cross-postings. == ICNS 2009 | Call for Papers === CALL FOR PAPERS, TUTORIALS, PANELS ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html Important deadlines: Submission (full paper) November 1, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks = ICNS 2009 Chairs: General Chair: Jaime Lloret Mauri, Polytechnic University of Valencia, Spain TPC Chairs: Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China Advisory Board Chair: Petre Dini, Cisco, USA ICNS 2009 Industry Chairs: Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland --
Re: InterCage, Inc. (NOT Atrivo)
On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: On Thursday 11 September 2008 06:23:29 [EMAIL PROTECTED] wrote: This is not a court. In court, if you are determined guilty a large punishment may be exacted Depeering is not a large punishment? In the internet world, mass depeering / de-transitting like we've see in this instance is akin to capital punishment. By vigilantes. The US Old West redux. You are confused. Connecting to my network is a PRIVILEGE, not a right. You lose a criminal case, you lose rights (e.g. freedom to walk outside). Disconnecting you from my network is not denying any of your rights. There is no law or even custom stopping me from asking you to prove you are worthy to connect to my network. You don't want to prove it, that's your right, just as it is my right to not connect to you. Mind if I ask why you think you have any right to connect to my network if I do not want you to do so? For _any_ reason, including not showing me legit customers, political affiliation, or even the color of your hat? -- TTFN, patrick But even in a court of law in a criminal case a defense must be made, otherwise the least sort of evidence of culpability can produce conviction; the defendant must at least put on a defense to invalidate the culpatory evidence. So when culpatory evidence is presented in these cases, requesting exculpatory evidence is very reasonable. Lack of a defense in a civil case will virtually guarantee a favorable judgment for the plaintiff, however.
Re: InterCage, Inc. (NOT Atrivo)
On Sep 11, 2008, at 6:52 PM, Randy Bush wrote: In the internet world, mass depeering / de-transitting like we've see in this instance is akin to capital punishment. By vigilantes. The US Old West redux. Connecting to my network is a PRIVILEGE, not a right. You lose a criminal case, you lose rights (e.g. freedom to walk outside). Disconnecting you from my network is not denying any of your rights. There is no law or even custom stopping me from asking you to prove you are worthy to connect to my network. You don't want to prove it, that's your right, just as it is my right to not connect to you. Mind if I ask why you think you have any right to connect to my network if I do not want you to do so? For _any_ reason, including not showing me legit customers, political affiliation, or even the color of your hat? amidst all this high flyin' political theory discussion of rights, there is an elephant in the room. as conditions to merger/purchase, there were legal restrictions placed on one or more significant operators regarding [de-]peering (i.e. your statement above is significantly incorrect). my altzheimer's device tells me that those restrictions end 2008.12.31. expect change. The fact there is a temporary exception to the rule for two providers in the US who agreed to the exception for reasons other than peering / transit does not mean the rule is invalid. As for (some of?) the exceptions expiring at the end of this calendar year, I'm not at all certain it will be a sea change. Contrary to popular belief, the US is not the center of the Internet any more. And even if it were, those providers - even the two combined - are not the center of the US Internet. Besides, wouldn't that just prove the rule anyway? :) The 'Net has become much more egalitarian. I would think that you of all people Randy would applaud the internationalization and flattening of the Internet. -- TTFN, patrick
RE: InterCage, Inc. (NOT Atrivo)
amidst all this high flyin' political theory discussion of rights, there is an elephant in the room. as conditions to merger/purchase, there were legal restrictions placed on one or more significant operators regarding [de-]peering (i.e. your statement above is significantly incorrect). my altzheimer's device tells me that those restrictions end 2008.12.31. expect change. randy SBC end-date is 2009-Dec-31. Randy
Re: InterCage, Inc. (NOT Atrivo)
amidst all this high flyin' political theory discussion of rights, there is an elephant in the room. as conditions to merger/purchase, there were legal restrictions placed on one or more significant operators regarding [de-]peering (i.e. your statement above is significantly incorrect). my altzheimer's device tells me that those restrictions end 2008.12.31. expect change. The fact there is a temporary exception to the rule for two providers in the US who agreed to the exception for reasons other than peering / transit does not mean the rule is invalid. so sorry to have interrupted a deep discussion of political theory on rights and unwritten rules with operational reality :) randy
Re: InterCage, Inc. (NOT Atrivo)
On Thursday 11 September 2008 18:37:59 Patrick W. Gilmore wrote: On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: On Thursday 11 September 2008 06:23:29 [EMAIL PROTECTED] wrote: This is not a court. In court, if you are determined guilty a large punishment may be exacted Depeering is not a large punishment? In the internet world, mass depeering / de-transitting like we've see in this instance is akin to capital punishment. By vigilantes. The US Old West redux. You are confused. No, I'm not, actually. As you say, it's every man (peer) for himself; is this not a digital analog to the dynamic of the Old West? If I have either a peering agreement or a transit arrangement with a written contract, then that contract supports my 'rights' under that contract persuant to my responsibilities being fulfilled. But here on NANOG it sure looked like the gunfight at the OK Corral earlier as the posse went after the bad guys. And, well, yes, the alleged 'bad guys' might have deserved the penalty. But it was sure an interesting dynamic to watch. Go back and read the whole thread; it is very enlightening. But you don't have to get all defensive about it.
Charter weirdness...
Anyone here with Charter? Please contact me off-list unless you're already aware of DNS weirdness... Jeff
Re: InterCage, Inc. (NOT Atrivo)
On Sep 11, 2008, at 9:11 PM, Lamar Owen wrote: On Thursday 11 September 2008 18:37:59 Patrick W. Gilmore wrote: On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: On Thursday 11 September 2008 06:23:29 [EMAIL PROTECTED] wrote: This is not a court. In court, if you are determined guilty a large punishment may be exacted Depeering is not a large punishment? In the internet world, mass depeering / de-transitting like we've see in this instance is akin to capital punishment. By vigilantes. The US Old West redux. You are confused. No, I'm not, actually. We disagree. As you say, it's every man (peer) for himself; is this not a digital analog to the dynamic of the Old West? If I have either a peering agreement or a transit arrangement with a written contract, then that contract supports my 'rights' under that contract persuant to my responsibilities being fulfilled. If you had ever read a peering agreement, you would know they contain no guarantees of connectivity. Your rights are actually set forth as to what you may not do (e.g. point default), not what you may do (e.g. connect to me). Well, unless you include disconnect from me as a right. As for transit agreements, note that the network in question was kicked off both its transit providers in essentially nothing flat, so they obviously are not guaranteed either. (Not to mention at least two more the transit providers previous to this thread.) But here on NANOG it sure looked like the gunfight at the OK Corral earlier as the posse went after the bad guys. And, well, yes, the alleged 'bad guys' might have deserved the penalty. But it was sure an interesting dynamic to watch. Go back and read the whole thread; it is very enlightening. Perhaps you should read up more on the alleged bad guys. I like to think of myself as a very open minded person, but child pr0n tends to upset essentially everyone. (And no, we are not talking 17 year olds, or even teenagers.) But you don't have to get all defensive about it. Not defensive, educational. From the tone and content of your posts, I made the - perhaps erroneous - assumption you were unclear on how and why networks interconnected. But to try and verify my assumption, I asked you a question, which you ignored: Mind if I ask why you think you have any right to connect to my network if I do not want you to do so? Although you verified my assumption anyway (see point you tried to make about peering agreements above). That said, I like to understand the root of your confusion, so I am still interested in your answer. -- TTFN, patrick
