[Nanog-futures] NANOG Wiki taken over by outsiders (Yes, I already sent an email to Richard)
I received a notification timestamped last night (3/27/2012 11:30PM), that said the main page of the NANOG Wiki had been changed by Snowing and since that didn't sound like anyone on NANOG, I looked. It's now devoted to advertisements. Luckily there are no drive by links, but I suppose that's next. Sorry to be the bearer of bad tidings. I sent an email earlier to ras@e-gerbil, and am now widening the scope of notification. Perhaps someone else here has the ability to fix it, or at least to back out the changes. The specific Subject line in the email was NANOG page Talk:Main Page has been changed by Snowing -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] NANOG Wiki taken over by outsiders (Yes, I already sent an email to Richard)
On 3/28/2012 8:24 AM, Joe Provo wrote: It has been this way for ages. Auto account creation was spamifying it into uselessless since at least 2009. After unspamming and reporting a couple times and the contact address I used for contributing getting placed on loads of spammer lists, I just presumed it was another dead project. Given that there was no collective management, common content sandards, or structure it was kinda stumbling anyway. Guess they just finally hit a page I'd edited. Too bad, really. This particular email address already receives so much spam (mostly trapped on the server, thank goodness) that I wouldn't notice any change in the levels. I suppose it would be wise for me to remove my account from there. Thanks very much for the update. It certainly shows that I hadn't paid it much attention, if it's been happening since 2009. Still sad, though. -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc)
Hi Nice discussion. Just a small question here - how much backhaul at present 2G, 3G and LTE based towers have? Just curious to hear an average number. I agree it would be a significant difference from busy street in New York to less crowded area say in Michigan but what sort of bandwidth telcos provision per tower? On fiber - I can imagine virtually unlimited bandwidth with incremental cost of optical instruments but how much to wireless backhaul based sites? Do they put Gigabit microwave everywhere? If not then say 100Mbps? If so then how end users on Verizon LTE people individual users get 10Mbps and so on? Is that operated at high contention? Thanks! (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 27, 2012 10:26 PM, Alexander Harrowell a.harrow...@gmail.com wrote: On Tue, Mar 27, 2012 at 1:45 AM, William Herrin b...@herrin.us wrote: On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard shadowedstrangerli...@gmail.com wrote: Who knows what technology will be like in 5-10 years? That's the whole point of what he was trying to say. Maybe wireless carriers will use visible wavelength lasers to recievers on top of customer's houses for all we know. 10 years is a LONG time for tech, and anything can happen. Regarding lasers. I agree that modulating a laser beam to carry information is a great idea. Perhaps, though, we could direct the beam down some sort of optical pipe or waveguide to spare ourselves the refractive losses and keep the pigeons and rain and whatnot out of the Fresnel zone. We might call it an optical wire or optical fibre or something. no, it'll never catch on... Hi Jacob, The scientists doing the basic research now know. It's referred to as the technology pipeline. When someone says, that's in the pipeline they mean that the basic science has been discovered to make something possible and now engineers are in the process of figuring out how to make it _viable_. The pipeline tends to be 5 to 10 years long, so basic science researchers are making the discoveries *now* which will be reflected in deployed technologies 10 years from now. I recall an Agilent Technologies presentation from a couple of years back that demonstrated that historically, the great majority of incremental capacity on cellular networks was accounted for by cell subdivision. Better air interfaces help, more spectrum helps, but as the maximum system throughput is roughly defined by (spectral efficiency * spectrum)* number of cells (assuming an even traffic distribution and no intercell interference or re-use overhead, for the sake of a finger exercise), nothing beats more cells. As a result, the Wireless Pony will only save you if you can find a 10GigE Backhaul Pony to service the extra cells. After a certain degree of density, you'd need almost as much fibre (and more to the point, trench mileage) to service a couple of small cells per street as you would to *pass the houses in the street with fibre*. One of the great things FTTH gets you is a really awesome backhaul network for us cell heads. One of the reasons we were able to roll out 3G in the first place was that DSL got deployed and you could provision on two or a dozen DSL lines for a cell site. You can't have wireless without backhaul (barring implausible discoveries in fundamental mesh network theory). Most wireless capacity comes from cell subdivision. Subdivision demands more backhaul. There is *nothing* promising in the pipeline for wireless tech that has any real chance of leading to a wide scale replacement for fiber optic cable. *Nothing.* Which means that in 10 years, wireless will be better, faster and cheaper but it won't have made significant inroads replacing fiber to the home and business. 20 years is a long time. 10 years, not so much. Even for the long times, we can find the future by examining the past. The duration of use of the predecessor technology (twisted pair) was about 50 years ubiquitously deployed to homes. From that we can make an educated guess about the current one (fiber). Fiber to the home started about 10 years ago leaving about 40 more before something better might replace it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Muni Fiber
Charles; Wouldn't Federal and State laws preempt Municipal law in this area? I agree YANAL. regards, Fletcher On Wed, Mar 28, 2012 at 1:06 AM, Charles Gucker cguc...@onesc.net wrote: On Wed, Mar 28, 2012 at 12:45 AM, Frank Bulk frnk...@iname.com wrote: I don't think a muni can prevent the ILEC from installing fiber in their RoW First off, IANAL, Secondly, I've had a reasonable amount of experience with Village and Municipal Law.In short, the statement above is incorrect, in so much that the RoW is not that of the ILEC, but rather the ILEC's ability to use the Muni's RoW.So, if the Municipality wanted to prevent the ILEC, or any company with RoW use rights, they certainly can. Unfortunately, a lot of the terms of the arrangement between the Municipalities and Telco's were written back in the 20's and 30's.So, the restriction would have to be put into terms of that agreement. But in the end, it's up to the Municipality to set the guidelines (as with any local law) within the borders of their Municipality. charles -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134
RPKI support from router verndors
Hello all, I was wondering when can we actually expect RPKI / origin validation support from router vendors. I know where Cisco and Juniper stand, in fact, I have been testing both implementations. So, I would like to know if some one has heard anything from: - Huawei - Alcatel - Others ? regards Carlos
Re: Muni Fiber
Charles Gucker wrote: On Wed, Mar 28, 2012 at 12:45 AM, Frank Bulkfrnk...@iname.com wrote: I don't think a muni can prevent the ILEC from installing fiber in their RoW First off, IANAL, Secondly, I've had a reasonable amount of experience with Village and Municipal Law.In short, the statement above is incorrect, in so much that the RoW is not that of the ILEC, but rather the ILEC's ability to use the Muni's RoW.So, if the Municipality wanted to prevent the ILEC, or any company with RoW use rights, they certainly can. Unfortunately, a lot of the terms of the arrangement between the Municipalities and Telco's were written back in the 20's and 30's.So, the restriction would have to be put into terms of that agreement. But in the end, it's up to the Municipality to set the guidelines (as with any local law) within the borders of their Municipality. (Talking US only...) Guess you weren't around when the Telecom Act hit... you mean anybody who wants to can dig up our streets to lay cable??? And today's cable franchising exercises have become almost a joke - given the restrictions implied by Federal and State laws. Re. terms that were written in the 20s and 30s... where it gets really interesting are places like Texas, where there are perpetual ROW grants that predate statehood, and can not be rewritten or renegotiated. Also some interesting legacies from ROW grants associated with building the transcontinental railroads (e.g., the City of Abilene, TX has to pay the Southern Pacific Railroad, or its successor, to run fiber along underpasses where their tracks bisect the City). -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Muni Fiber
On Wed, Mar 28, 2012 at 7:56 AM, Fletcher Kittredge fkitt...@gwi.net wrote: Wouldn't Federal and State laws preempt Municipal law in this area? Hi Fletcher, State laws yes. State legislatures tend to narrowly define what laws a municipality is allowed to independently enact. And they tend to be very open to the proposition that standards for utility construction should be uniform across the state. Federal, maybe. The FCC has overstepped its authority and been overruled by the courts many times. And municipal laws can be carefully enough constructed that preemption would unambiguously exceed federal authority. Even if preempted, a state or municipality can make it make it *very* uncomfortable for a communications provider who doesn't want to play ball. Consider, for example, DC's repaving requirements: if you dig up the street, you're required to repave the whole street all the way from the nearest intersections. Completely repave, not just cold-patch. That's pretty expensive. Unless they waive the requirement on a case by case basis. Where the basis has a habit of being whether or not your digging is in line with a government policy objective. This is one reason FIOS deployments lag in DC. Verizon doesn't want to deploy conduit down every street lest they be compelled to open it to competitors and the DC government won't waive the repaving requirements for direct burial fiber. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Muni Fiber
William Herrin wrote: Even if preempted, a state or municipality can make it make it *very* uncomfortable for a communications provider who doesn't want to play ball. Consider, for example, DC's repaving requirements: if you dig up the street, you're required to repave the whole street all the way from the nearest intersections. Completely repave, not just cold-patch. That's pretty expensive. Unless they waive the requirement on a case by case basis. Where the basis has a habit of being whether or not your digging is in line with a government policy objective. This is one reason FIOS deployments lag in DC. Verizon doesn't want to deploy conduit down every street lest they be compelled to open it to competitors and the DC government won't waive the repaving requirements for direct burial fiber. Flip side of this - a street cut, on average, take a year off the life of a street. Street patches tend to lead to potholes, ice dams, and so forth (and from there to lots of car repairs). Doing things in the street disrupts traffic - you don't want it to happen too often. (Things you learn consulting to local governments.) It's not a matter of making things uncomfortable for communications providers - it's a matter of getting them to pay the full cost of digging, rather than passing it off to others. It's been my observation that MOST municipalities let providers do whatever they want, don't do anything to coordinate right-of-way work (even by their own water departments), don't have the budget to repair or repave roads all that often, and hence have absolutely horrid roads - particularly in areas where water infiltration and freezing is an issue. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
BCP38 Deployment
Hi all, I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is on source address validation. Although BCP38 was proposed more than ten years ago, IP spoofing still remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report] [Presentation on NANOG Meeting] [Discussion in NANOG ML]. I did a lot investigation, but still have no idea why so many ISPs haven't deploy BCP38. I enumerate three reasons I found, and I'd like your comments very much. 1. Stub ASes: They rely on their providers to filter, so they won't deploy BCP38 on their own. 2. Low tier transit ASes: They are most likely to deploy BCP38 on the interfaces towards their customers. 3. Large or tier1 ASes: Their peers and customers are also large. So uRPF may have false positive and ACLs are too large to manage. I also asked some ISP guys in IETF today, they all agreed that IP spoofing is an issue, but they may haven't deployed it. One key issue, I think, is about incentive. i.e. you can filter, but you'll still receive spoofing from providers and peers who haven't enforced BCP38. best Bingyang -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Re: BCP38 Deployment
On Mar 28, 2012, at 10:44 , Bingyang LIU wrote: I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is on source address validation. Although BCP38 was proposed more than ten years ago, IP spoofing still remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report] [Presentation on NANOG Meeting] [Discussion in NANOG ML]. I did a lot investigation, but still have no idea why so many ISPs haven't deploy BCP38. I enumerate three reasons I found, and I'd like your comments very much. 1. Stub ASes: They rely on their providers to filter, so they won't deploy BCP38 on their own. 2. Low tier transit ASes: They are most likely to deploy BCP38 on the interfaces towards their customers. 3. Large or tier1 ASes: Their peers and customers are also large. So uRPF may have false positive and ACLs are too large to manage. I also asked some ISP guys in IETF today, they all agreed that IP spoofing is an issue, but they may haven't deployed it. One key issue, I think, is about incentive. i.e. you can filter, but you'll still receive spoofing from providers and peers who haven't enforced BCP38. While those reasons are somewhat valid, they are not the main reasons. #1) Money. Whenever someone asks why...?, the answer is usually money. It costs money - CapEx if your equipment doesn't support RPF, and OpEx even if it does. Plus opportunity cost if your customers don't like it or you screw up, as those customers will find someone who doesn't filter and move. #2) Laziness. When the question is why have [you|they] not...?, the second most common answer is laziness. Some call it inertia, but reality is people are busy, lazy, etc. Please note the complete lack of smilies or other indication I am kidding or being sarcastic. There is also ignorance, stupidity, malice (yes, some people actually attack others or sell to those who do), etc. -- TTFN, patrick
Re: Force10 E Series at the edge?
I can't speak for forece10 which is DELL now. As Joe mentioned, the biggest problem is their-support of 680k prefixes with the QUAD-CAM linecards. DUAL-CAM line cards do 512K in theory. Regular ones don't work because thay support 320K prefifex and die around 300K If memory serves, it's worse than that. Those numbers can only be achieved if you turn off IPv6 altogether IIRC. Owen
Re: BCP38 Deployment
In a message written on Wed, Mar 28, 2012 at 11:00:39AM -0400, Patrick W. Gilmore wrote: #1) Money. Whenever someone asks why...?, the answer is usually money. It costs money - CapEx if your equipment doesn't support RPF, and OpEx even if it does. Plus opportunity cost if your customers don't like it or you screw up, as those customers will find someone who doesn't filter and move. #2) Laziness. When the question is why have [you|they] not...?, the second most common answer is laziness. Some call it inertia, but reality is people are busy, lazy, etc. While Patrick is spot on, there is a third issue which is related to money and laziness, but also has some unique aspects. BCP38 makes the assumption that the ISP does some configuration to insure only properly sourced packets enter the network. That may have been true when BCP38 was written, but no longer accurately reflects how networks are built and operated. To get source address validation widely deployed it needs to be baked into consumer CPE. The requirement needs to be a default on in the DOCSYS specs, for instance. Residential gateways need to come from the factory with unicast RPF turned on. BCP38 needs to be applied at the OEM level in equipment maufacturing, not at the operational level with ISP's. There are, simply, too many variations in CPE devices to expect ISP's to _configure_ them. Even when the configuration is standardized (like DOCSYS) ISP's have to think really hard about the operational impact of turning on a feature; and one buggy implementationc can scuttle an idea network wide. Which really comes back to Patrick's point #2. If the people who care about this want to see a positive change they need to stop badgering ISP's to implement BCP38 and start badgering Linksys/Netgear/D-Link/Motorola/Apple/Touchstone/SMC/Westtel to make unicast RPF a default part of their gateway implementation. More importantly, they need to get them to brand it as a _feature_, protect your computer from being used by hackers, our router insures they won't use up all of your data cap! Then it will be something they can sell, and thus something they will implement. As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp37RSWtgIkP.pgp Description: PGP signature
Re: Muni Fiber
- Original Message - From: Frank Bulk frnk...@iname.com I don't think a muni can prevent the ILEC from installing fiber in their RoW Their: pronoun without a referent. The municipality's right of way? I should think they would be able to; the property, or the easement, is theirs, not any utility's. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Muni Fiber
Jay Ashworth wrote: - Original Message - From: Frank Bulkfrnk...@iname.com I don't think a muni can prevent the ILEC from installing fiber in their RoW Their: pronoun without a referent. The municipality's right of way? I should think they would be able to; the property, or the easement, is theirs, not any utility's. Think again. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
RE: Force10 E Series at the edge?
-Original Message- From: Tom Daly Sent: Tuesday, March 27, 2012 8:59 PM To: Brent Roberts Cc: NANOG Subject: Re: Force10 E Series at the edge? Brent, Your options include, for smaller boxes: - Brocade CER series, but make sure you the -RT versions due to RAM (haven't tried, though) - Juniper MX (MX80 is working well for us) - Cisco ASR1006 (heard a lot about BGP price issues) But for 300mb/sec, what not OpenBSD + Quagga? Tom I have been using a pair of CER (but not the -RT) at one location for a while now and so far have been flawless. These particular units aren't taking full tables so don't need the -RT but I wouldn't have any trouble using them. The -RT are basically a 1U XMR.
Re: BCP38 Deployment
Leo, On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: #1) Money. #2) Laziness. While Patrick is spot on, there is a third issue which is related to money and laziness, but also has some unique aspects. BCP38 makes the assumption that the ISP does some configuration to insure only properly sourced packets enter the network. That may have been true when BCP38 was written, but no longer accurately reflects how networks are built and operated. An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? BCP38 needs to be applied at the OEM level in equipment maufacturing, not at the operational level with ISP's. I don't believe this is either/or. I agree that BCP38 features should be turned on by default in CPE, however I believe it really needs to be enforced at the ISP level. As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. Optimist. Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Regards, -drc
Re: Force10 E Series at the edge?
Brant Ian Stevens mailto:bra...@argentiumsolutions.com March 28, 2012 11:41 AM The CER is the perfect box for this application, save for the redundant processors. The MLXe will work great if you want a small form factor and redundant processors. -Brant George Bonser mailto:gbon...@seven.com March 28, 2012 11:34 AM I have been using a pair of CER (but not the -RT) at one location for a while now and so far have been flawless. These particular units aren't taking full tables so don't need the -RT but I wouldn't have any trouble using them. The -RT are basically a 1U XMR. Tom Daly mailto:t...@dyn.com March 27, 2012 11:59 PM Brent, Your options include, for smaller boxes: - Brocade CER series, but make sure you the -RT versions due to RAM (haven't tried, though) - Juniper MX (MX80 is working well for us) - Cisco ASR1006 (heard a lot about BGP price issues) But for 300mb/sec, what not OpenBSD + Quagga? Tom - Original Message - Jo Rhett mailto:jrh...@netconsonance.com March 27, 2012 6:00 PM I was very happy with the E300 as a data center core switch handling multiple full feeds (around 15) with about 10x the traffic you are talking about. The only problem I had was that Force10 didn't have a useful (basically forklift) upgrade to get more IPv4 prefixes, and the more I talked to them and the more I showed them the graphs demonstrating what we'd need for prefix space assuming even the most conservative assumptions at depletion, the more I realized they really Did Not Get It. In fact, their brand new architecture recently announced had only 500k prefixes allowed, at a time that the Juniper MX platform handled 2million easily. So I would be fine using Force10 again, given the following changes: 1. Large limits on IP prefixes allowed 2. Reallocation of useless memory from stupid things like MAC tables to prefixes (data centers have very few MACs, very many prefixes) 3. Command line logging The units worked great at failover, never had any problems gracefully failing over from one RP to another, but if you have to cold boot them for any reason it takes like 5 minutes :(
Re: BCP38 Deployment
Hi David, Leo, Patrick and all, Considering the reasons you raised, do you think the following two things can happen? 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well protect its customers by implementing BCP38? I don't think so, because I think BCP38 is accurate near the source but inaccurate near the destination, i.e. if its customer is the target of spoofing attack, its capability to filter is relatively low. 2. Even if ineffective near the destination, is an ISP willing to deploy it if it becomes easy to adopt and risk-free (no false positive)? Sorry for my stupid and naive questions. best Bingyang On Wed, Mar 28, 2012 at 5:45 PM, David Conrad d...@virtualized.org wrote: Leo, On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: #1) Money. #2) Laziness. While Patrick is spot on, there is a third issue which is related to money and laziness, but also has some unique aspects. BCP38 makes the assumption that the ISP does some configuration to insure only properly sourced packets enter the network. That may have been true when BCP38 was written, but no longer accurately reflects how networks are built and operated. An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? BCP38 needs to be applied at the OEM level in equipment maufacturing, not at the operational level with ISP's. I don't believe this is either/or. I agree that BCP38 features should be turned on by default in CPE, however I believe it really needs to be enforced at the ISP level. As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. Optimist. Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Regards, -drc -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Re: BCP38 Deployment
In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote: An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? Well, RFC3704 for one has updated the methods and tactics since BCP38 was written. Remember BCP38 was before even unicast RPF as we know it existed. Some relevant points from 3704: 3. Clarifying the Applicability of Ingress Filtering What may not be readily apparent is that ingress filtering is not applied only at the last-mile interface between the ISP and the end user. It's perfectly fine, and recommended, to also perform ingress filtering at the edges of ISPs where appropriate, at the routers connecting LANs to an enterprise network, etc. -- this increases the defense in depth. 5. Security Considerations [snip] The closer to the actual source ingress filtering is performed, the more effective it is. One could wish that the first hop router would ensure that traffic being sourced from its neighboring end system was correctly addressed; a router further away can only ensure that it is possible that there is such a system within the indicated prefix. Therefore, ingress filtering should be done at multiple levels, with different level of granularity I'm not saying ISP's can't or couldn't do it, what I am saying, and RFC 3704 is repeating, is that it is cheaper/easier/faster and more reliable to do it as close to the edge as possible. The edge is not the edge of the ISP network, it is the edge of the entire network, that is the /last router in the topology/. Today that last router is owned and operated by the customer in most cases. So if a provider drops off a modem with your service that also does WiFi and the customer simply uses it, the provider is 100% responsible for doing BCP 38, in my estimation. But as soon as the consumer buys a routing device they become 100% on the hook for now operating the last mile, and it is that device where the primary filtering should take place. ISP's may still filter, for a defense in depth, but they are no longer the edge of the network and as such their responsibility is greatly diminished in my view. BCP38 was written when a point to point handoff to a single customer was standard, and that's easy to filter. Today a shared medium (like a cable modem network) is common and more importantly connects to more routers (home gateways), rathern than PC's. That's a funamental change since BCP38 was written. I'll also point out that operating systems fill a role here as well. Many OS's won't let you spoof a layer 2 MAC address (try to write a packet with a raw interface and it overwrites the source address) but are happy to let an application send a packet with source layer 3 address that is forged! Sure, malware could always hack the OS too, but it raises the bar. The community should demand that all OS's default to not allowing L3 sources that aren't configured on the box from leaving that box. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp7BCaby85bh.pgp Description: PGP signature
Re: BCP38 Deployment
While I'm a big fan of RFP, it does require that operators be good citizens for it to be effective. Like most of the Internet, it's built on a web of trust. On Wed, Mar 28, 2012 at 12:10 PM, Bingyang LIU bjorn...@gmail.com wrote: Hi David, Leo, Patrick and all, Considering the reasons you raised, do you think the following two things can happen? 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well protect its customers by implementing BCP38? I don't think so, because I think BCP38 is accurate near the source but inaccurate near the destination, i.e. if its customer is the target of spoofing attack, its capability to filter is relatively low. 2. Even if ineffective near the destination, is an ISP willing to deploy it if it becomes easy to adopt and risk-free (no false positive)? Sorry for my stupid and naive questions. best Bingyang On Wed, Mar 28, 2012 at 5:45 PM, David Conrad d...@virtualized.org wrote: Leo, On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: #1) Money. #2) Laziness. While Patrick is spot on, there is a third issue which is related to money and laziness, but also has some unique aspects. BCP38 makes the assumption that the ISP does some configuration to insure only properly sourced packets enter the network. That may have been true when BCP38 was written, but no longer accurately reflects how networks are built and operated. An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? BCP38 needs to be applied at the OEM level in equipment maufacturing, not at the operational level with ISP's. I don't believe this is either/or. I agree that BCP38 features should be turned on by default in CPE, however I believe it really needs to be enforced at the ISP level. As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. Optimist. Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Regards, -drc -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Cisco Security Advisory: Cisco IOS Software Zone-Based Firewall Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Zone-Based Firewall Vulnerabilities Advisory ID: cisco-sa-20120328-zbfw Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +- Summary === Cisco IOS Software contains four vulnerabilities related to Cisco IOS Zone-Based Firewall features. These vulnerabilities are as follows: * Memory Leak Associated with Crafted IP Packets * Memory Leak in HTTP Inspection * Memory Leak in H.323 Inspection * Memory Leak in SIP Inspection Workarounds that mitigate these vulnerabilities are not available. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-zbfw Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products = Vulnerable Products +-- Cisco IOS devices running vulnerable versions of Cisco IOS Software are affected by four vulnerabilities in the Cisco IOS Zone-Based Firewall. The vulnerabilities are independent of each other. Details to confirm affected configurations are provided below. To determine whether a device is configured with Zone-Based Firewall, log in to the device and issue the show zone security command-line interface (CLI) command. If the output shows a member interface under a zone name, the device is vulnerable. The following example shows a device with Zone-Based Firewall rules configured on both GigabitEthernet0/0 and GigabitEthernet0/1: Router#show zone security zone self Description: System defined zone zone inside Description: *** Inside Network *** Member Interfaces: GigabitEthernet0/0 zone outside Description: *** Outside Network *** Member Interfaces: GigabitEthernet0/1 Router# The following sections provide more details on the specific features containing the vulnerabilities. Memory Leak Associated with Crafted IP Packets +- There is no specific configuration necessary for a device to be vulnerable to the memory leak associated with crafted IP packets. If the Zone-Based Firewall is configured, the device is vulnerable. Memory Leak in HTTP Inspection +- For the device to be vulnerable to the memory leak associated with HTTP inspection, the Zone-Based Firewall must be configured to perform HTTP inspection with the Zone-Based Firewall. To determine whether a device is configured for HTTP inspection, enter the command show policy-map type inspect zone-pair | include Match: protocol http. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall HTTP inspection: Router#show policy-map type inspect zone-pair | include Match: protocol http Match: protocol http Memory Leak in H.323 Inspection +-- For a device to be vulnerable to the memory leak associated with H.323 inspection, the Zone-Based Firewall must be configured to perform H.323 inspection. To determine if a device is configured for H.323 inspection enter the command show policy-map type inspect zone-pair | include Match: protocol h323. If the output contains Match: protocol h323 the device is vulnerable. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall H.323 inspection: Router# show policy-map type inspect zone-pair | include Match: protocol h323 Match: protocol h323 Memory Leak in SIP Inspection + The device is vulnerable if the configuration has either a Layer 4 or Layer 7 Session Initiation Protocol (SIP) application-specific policy configured, and the policy is applied to any firewall zone. To determine whether a device is configured for SIP inspection enter the command show policy-map type inspect zone-pair | include Match: protocol sip. If the output contains Match: protocol sip the device is vulnerable. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall SIP inspection: Router# show policy-map type inspect zone-pair | include Match: protocol sip Match: protocol sip To determine the Cisco IOS Software release
Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software Traffic Optimization Features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software Traffic Optimization Features Advisory ID: cisco-sa-20120328-mace Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) + Summary === Cisco IOS Software contains a denial of service (DoS) vulnerability in the Wide Area Application Services (WAAS) Express feature that could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Cisco IOS Software also contains a DoS vulnerability in the Measurement, Aggregation, and Correlation Engine (MACE) feature that could allow an unauthenticated, remote attacker to cause the router to reload. An attacker could exploit these vulnerabilities by sending transit traffic through a router configured with WAAS Express or MACE. Successful exploitation of these vulnerabilities could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Repeated exploits could allow a sustained DoS condition. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-mace Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/ Cisco_ERP_mar12.html Affected Products = Vulnerable Products +-- Cisco devices that are running Cisco IOS Software are vulnerable when they are configured with the mace enable or waas enable interface configuration commands on one or more interfaces. Additional configuration is required for WAAS Express or MACE to be configured; more details follow. Note: Cisco IOS Software is vulnerable only when configured for WAAS Express or MACE. Cisco IOS Software configured for WAAS, not WAAS Express, is not vulnerable. For more information on WAAS Express, see http://www.cisco.com/en/US/products/ps11211/index.html. For more information about MACE, see http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps11709/ps11671/guide_c07-664643.html. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The image name displays in parentheses, followed by Version and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software Reference Guide at http://www.cisco.com/web/about/security/intelligence/ios-ref.html. Products Confirmed Not Vulnerable + No other Cisco products are currently known to be affected by these vulnerabilities. Details === The Cisco Wide Area Application Services (WAAS) Express feature allows optimization of the WAN bandwidth required to access centrally located applications. WAAS Express allows the traffic to be optimized by a Cisco Integrated Services Router (ISR G2), with no other devices required. The Cisco Measurement, Aggregation, and Correlation Engine (MACE) is a Cisco IOS feature that is used for measurement and analysis of network traffic. The feature may be used with WAAS Express to give details of optimized traffic or used by itself to help measure application performance. Cisco IOS Software contains a DoS vulnerability in the WAAS Express feature that could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. This vulnerability is documented in Cisco bug ID CSCtt45381 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-1314. Cisco IOS Software
Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability Advisory ID: cisco-sa-20120328-nat Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) + Summary === The Cisco IOS Software Network Address Translation (NAT) feature contains a denial of service (DoS) vulnerability in the translation of Session Initiation Protocol (SIP) packets. The vulnerability is caused when packets in transit on the vulnerable device require translation on the SIP payload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates the vulnerability is available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-nat Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products = Vulnerable Products +-- Cisco devices that are running Cisco IOS Software are vulnerable when they are configured for NAT and contain support for NAT for Session Initiation Protocol. There are two methods to determine if a device is configured for NAT: * Determine if NAT is active on a running device. * Determine if NAT commands are included in the device configuration. Determine if NAT is Active on a Running Device +- The preferred method to verify whether NAT is enabled on a Cisco IOS device is to log in to the device and issue the show ip nat statistics command. If NAT is active, the sections Outside interfaces and Inside interfaces will each include at least one interface. The following example shows a device on which the NAT feature is active: Router#show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 Depending on the Cisco IOS Software release, the interface lists can be in the lines following the Outside interfaces and Inside interfaces. In releases that support the section filter on show commands, the administrator can determine whether NAT is active by using the show ip nat statistics | section interfaces command, as illustrated in the following example: Router show ip nat statistics | section interfaces Outside interfaces: GigabitEthernet0/0 Inside interfaces: GigabitEthernet0/1 Router Determine if NAT Commands are Included in the Device Configuration +- Alternatively, to determine whether NAT has been enabled in the Cisco IOS Software configuration, either the ip nat inside or ip nat outside commands must be present in different interfaces, or in the case of the NAT Virtual Interface, the ip nat enable interface command will be present. Determine the Cisco IOS Software Release +--- To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The image name displays in parentheses, followed by Version and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software
Re: BCP38 Deployment
On Wed, Mar 28, 2012 at 12:16, Leo Bicknell bickn...@ufp.org wrote: Well, RFC3704 for one has updated the methods and tactics since BCP38 was written. Remember BCP38 was before even unicast RPF as we know it existed. I think the concern of RFC3704/BCP84, i.e., multihoming, is the primary reason we don't see ingress filtering as much as we should. Almost any network worth its salt these days is multihomed, making strict RPF nearly impossible to pull off. Despite this, to my knowledge, Juniper is one of the only vendors that provides feasible-path RPF to deal with it. On Cisco and Brocade for example, you're stuck doing some dark voodoo magic with BGP weights communities + strict RPF (refer to the previous money and laziness points) to accomplish something that SHOULD be basic. -- Darius Jahandarie
Re: BCP38 Deployment
On Wed, 28 Mar 2012, David Conrad wrote: Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Exactly. Either do it voluntarily or it will be done for you involuntarily at the federal level and you will have nobody but yourselves to blame. The choice is yours. -Dan
Re: BCP38 Deployment
On Mar 28, 2012, at 9:39 AM, Darius Jahandarie wrote: I think the concern of RFC3704/BCP84, i.e., multihoming, is the primary reason we don't see ingress filtering as much as we should. I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Regards, -drc
Re: BCP38 Deployment
Yep, one way is to give economic penalty. But how about giving the _good_ ISPs economic reward? Say, some transit ISPs deploy anti-spoofing techniques (e.g. uRPF), but only filter those spoofing packets whose destination is the ASes having purchased their *anti-spoofing service* ? Bingyang On Wed, Mar 28, 2012 at 6:41 PM, goe...@anime.net wrote: On Wed, 28 Mar 2012, David Conrad wrote: Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Exactly. Either do it voluntarily or it will be done for you involuntarily at the federal level and you will have nobody but yourselves to blame. The choice is yours. -Dan -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Re: BCP38 Deployment
On 03/28/2012 09:16 AM, Leo Bicknell wrote: In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote: An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? Well, RFC3704 for one has updated the methods and tactics since BCP38 was written. Remember BCP38 was before even unicast RPF as we know it existed. I'm not saying ISP's can't or couldn't do it, what I am saying, and RFC 3704 is repeating, is that it is cheaper/easier/faster and more reliable to do it as close to the edge as possible. The edge is not the edge of the ISP network, it is the edge of the entire network, that is the /last router in the topology/. Today that last router is owned and operated by the customer in most cases. Yeahbut, the CPE isn't trusted. It would be _nice_ for customers to be bcp38 clueful as well, but I don't think it's _required_ for successful deployment from the ISP's standpoint. Even with a system like DOCSIS where the CPE is semi-trustworthy from a provisioning/etc standpoint, I don't think I'd _count_ on them. In any case, isn't RPF really cheap these days on edge aggregation routers? It's not like it's a new innovation or anything. BCP38 was written when a point to point handoff to a single customer was standard, and that's easy to filter. Today a shared medium (like a cable modem network) is common and more importantly connects to more routers (home gateways), rathern than PC's. That's a funamental change since BCP38 was written. DOCSIS was standardized in the mid to late 90's which more or less predates bcp 38, and it has always been able to handle multiple endpoints/modem. As I recall, there were specs for cable modem nics for individual machines, but they never took off. Mike
Re: BCP38 Deployment
On 3/28/12 11:45 AM, David Conrad wrote: Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. in a note (which didn't go anywhere in particular) i pointed out that contract may address the same issue for which legislation may be proposed, at least for contractual closures (sorry, a term of my own, defined below) which share the property some jurisdictions have of a finite access provider universe. i mean contractual closure to be the performance guarantee (or non-performance guarantee) present in a set of contracts for a particular service. think china, after first abstracting all the negatives associated with policy as a property of a distributed, shared, public resource, or firewalls 4 (bcp defined) good. -e
Cisco Security Advisory: Cisco IOS Software RSVP Denial of Service Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software RSVP Denial of Service Vulnerability Advisory ID: cisco-sa-20120328-rsvp Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +- Summary === Cisco IOS Software and Cisco IOS XE Software contain a vulnerability in the RSVP feature when used on a device configured with VPN routing and forwarding (VRF) instances. This vulnerability could allow an unauthenticated, remote attacker to cause an interface wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other denial of service (DoS) conditions. This vulnerability could be exploited repeatedly to cause an extended DoS condition. A workaround is available to mitigate this vulnerability. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-rsvp Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products = Vulnerable Products +-- Only devices with specific configurations are affected. Cisco devices that are running affected Cisco IOS Software or Cisco IOS XE Software versions are vulnerable when they are configured with RSVP and also have one or more VRF interfaces. A device is vulnerable if both the following criteria are met: * At least one VRF is configured without RSVP * At least one other interface (physical or virtual), not in the same VRF, is configured with RSVP Some example scenarios are as follows: * RSVP-Traffic Engineering (RSVP-TE) in Multiprotocol Label Switching (MPLS) infrastructures * Multi-VRF infrastructures * VRF-Lite infrastructures To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The image name displays in parentheses, followed by Version and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in White Paper: Cisco IOS and NX-OS Software Reference Guide at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable + Cisco IOS-XR software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details === Cisco IOS Software and Cisco IOS XE Software contain a vulnerability in the RSVP feature when used on a device configured with VPN routing and forwarding (VRF) instances. This vulnerability could allow an unauthenticated, remote attacker to cause an interface wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other denial of service (DoS) conditions. This vulnerability could be exploited repeatedly to cause an extended DoS condition. A device is vulnerable if it is configured with VRF and none of the interfaces in that VRF have RSVP enabled, but any other interface (physical or virtual) does have RSVP enabled. An attacker with some knowledge of the affected infrastructure could exploit this vulnerability by sending RSVP packets to vulnerable devices. Successful exploitation of the vulnerability could allow an attacker to wedge the receive queue of any RSVP ingress interface. A workaround is available to mitigate this vulnerability. In devices that meet the vulnerable configuration criteria, valid RSVP packets could trigger this vulnerability. An attacker with knowledge
Re: BCP38 Deployment
Yeah, contractual closures might be a way to force the providers to deploy BCP38. However, when the customers become the target of a spoofing attack, the provider may not be able to protect its customers, because ingress filtering (including uRPF) is inefficient when done near the destination. In other words, an ISP can deploy BCP38 or whatever, but still cannot well protect its customers from spoofing attacks from other ASes. On Wed, Mar 28, 2012 at 6:54 PM, Eric Brunner-Williams brun...@nic-naa.net wrote: On 3/28/12 11:45 AM, David Conrad wrote: Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with cyber- tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. in a note (which didn't go anywhere in particular) i pointed out that contract may address the same issue for which legislation may be proposed, at least for contractual closures (sorry, a term of my own, defined below) which share the property some jurisdictions have of a finite access provider universe. i mean contractual closure to be the performance guarantee (or non-performance guarantee) present in a set of contracts for a particular service. think china, after first abstracting all the negatives associated with policy as a property of a distributed, shared, public resource, or firewalls 4 (bcp defined) good. -e -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Re: BCP38 Deployment
On Wed, Mar 28, 2012 at 12:50, David Conrad d...@virtualized.org wrote: I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Yes, but RPF can be implemented in places other than the customer edge. In those places, lack of widespread, easy, and vendor-supported feasible-path uRPF is what I believe really hurts things. Granted, this is along a different line than what the OP was talking about, but in terms of answering the question of why don't we see ingress filtering as much as we should?, I think it's a large factor. -- Darius Jahandarie
Re: BCP38 Deployment
On Wed, 28 Mar 2012, Bingyang LIU wrote: the provider may not be able to protect its customers, because ingress filtering (including uRPF) is inefficient when done near the destination. In other words, an ISP can deploy BCP38 or whatever, but still cannot well protect its customers from spoofing attacks from other ASes. The ASes which enable spoofing need to have some penalty imposed or they will never engage in correct behavior. Something like throwing all their traffic into scavenger class. If their customers start complaining to them, maybe then they will shape up. -Dan
Re: BCP38 Deployment
Hi Darius, Yes, I agree that feasible RPF solves the problem in a lot of scenarios. However, in some other cases, the asymmetric routing is caused by static routing, traffic engineering, policy routing, etc., where the lengths of forward path and reverse path may differ, so feasible RPF may also fail (false positive). Bingyang On Wed, Mar 28, 2012 at 7:07 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Mar 28, 2012 at 12:50, David Conrad d...@virtualized.org wrote: I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Yes, but RPF can be implemented in places other than the customer edge. In those places, lack of widespread, easy, and vendor-supported feasible-path uRPF is what I believe really hurts things. Granted, this is along a different line than what the OP was talking about, but in terms of answering the question of why don't we see ingress filtering as much as we should?, I think it's a large factor. -- Darius Jahandarie -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Quad-A records in Network Solutions ?
Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. It's ok to contact me privately. regards Carlos
Re: Quad-A records in Network Solutions ?
I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. I've had them set up in the past by e-mailing ipv6...@networksolutions.com.
Re: Quad-A records in Network Solutions ?
Hi Carlos, You are right... I just entered with my account and after I clicked Edit DNS there is a dialog box which says: Advanced Users: To specify your IPv6 name server address (IPv6 glue record), e-mail us the domain name, the host name of the name server(s), and their IPv6 address(es). See you, Alejandro, On 3/28/12, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. It's ok to contact me privately. regards Carlos
Re: Quad-A records in Network Solutions ?
Yup... I was reading the same page myself. Pretty sad. My friend just forwarded me the response from NSI Support. Incredibly lame. I'm tempted to share it here, but my good twin told me not to. I'm recommending they switch registrars. regards, Carlos On 3/28/12 2:57 PM, Alejandro Acosta wrote: Hi Carlos, You are right... I just entered with my account and after I clicked Edit DNS there is a dialog box which says: Advanced Users: To specify your IPv6 name server address (IPv6 glue record), e-mail us the domain name, the host name of the name server(s), and their IPv6 address(es). See you, Alejandro, On 3/28/12, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. It's ok to contact me privately. regards Carlos
Re: Quad-A records in Network Solutions ?
And they need to do anyway, if they want to keep the contract: http://www.ipv6tf.org/index.php?page=news/newsroomid=8494 Regards, Jordi -Mensaje original- De: Jeff Fisher na...@techmonkeys.org Responder a: na...@techmonkeys.org Fecha: Wed, 28 Mar 2012 11:53:35 -0600 Para: nanog@nanog.org Asunto: Re: Quad-A records in Network Solutions ? I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure 's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting 's. I've had them set up in the past by e-mailing ipv6...@networksolutions.com. ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
RE: BCP38 Deployment
Also, Don't forget that transit providers currently bill their customers to carry that spoofed/DoS traffic, why would they filter it when it's on their balance sheets? -Drew -Original Message- From: Bingyang LIU [mailto:bjorn...@gmail.com] Sent: Wednesday, March 28, 2012 1:15 PM To: Darius Jahandarie Cc: NANOG list Subject: Re: BCP38 Deployment Hi Darius, Yes, I agree that feasible RPF solves the problem in a lot of scenarios. However, in some other cases, the asymmetric routing is caused by static routing, traffic engineering, policy routing, etc., where the lengths of forward path and reverse path may differ, so feasible RPF may also fail (false positive). Bingyang On Wed, Mar 28, 2012 at 7:07 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Wed, Mar 28, 2012 at 12:50, David Conrad d...@virtualized.org wrote: I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Yes, but RPF can be implemented in places other than the customer edge. In those places, lack of widespread, easy, and vendor-supported feasible-path uRPF is what I believe really hurts things. Granted, this is along a different line than what the OP was talking about, but in terms of answering the question of why don't we see ingress filtering as much as we should?, I think it's a large factor. -- Darius Jahandarie -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby
Re: Quad-A records in Network Solutions ?
On 3/28/2012 10:59 AM, JORDI PALET MARTINEZ wrote: And they need to do anyway, if they want to keep the contract: http://www.ipv6tf.org/index.php?page=news/newsroomid=8494 This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. To quote: We don't have a customer interface for IPv6 glue records on name servers. However, we can manually set them up if you can send us the information for the records. That's probably okay for me, but it's really not conducive to any large scale operation. It needs to be run-of-the-mill, and not esoteric, to move it forward. -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx
Re: Quad-A records in Network Solutions ?
I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? regards Carlos On 3/28/12 3:40 PM, Lynda wrote: On 3/28/2012 10:59 AM, JORDI PALET MARTINEZ wrote: And they need to do anyway, if they want to keep the contract: http://www.ipv6tf.org/index.php?page=news/newsroomid=8494 This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. To quote: We don't have a customer interface for IPv6 glue records on name servers. However, we can manually set them up if you can send us the information for the records. That's probably okay for me, but it's really not conducive to any large scale operation. It needs to be run-of-the-mill, and not esoteric, to move it forward.
Re: FW: Force10 E Series at the edge?
On 3/27/12 23:21 , Roberts, Brent wrote: Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP session count would be between 2 and 4 Peers. 6k internal Prefix count as it stands right now. Alternative are welcome. Thought about the ASR1006 but I need some local switching as well. Doesn't support URPF which makes it unsuitable for RTBH and therefore customer or transit edge IMHO. I do use them and like them reasonably well for high density over-subscription 10Gb/s ports. Can get 280 2x oversubscribed 10Gb/s ports or 560 4x layer 3 out of an e1200i. Full requirements include Full internet Peering over GigE Links. Fully Redundant Power Redundant Supervisor/Route Processor Would prefer a Small Chassis unit. (under 10u) Would also prefer a single unit as opposed to a two smaller units. This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email.
Re: Quad-A records in Network Solutions ?
Once upon a time, Lynda shr...@deaddrop.org said: This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. The same problem exists for DNSSEC; the number of registrars that support both IPv6 glue and DNSSEC in their standard interfaces is unfortunately small. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Quad-A records in Network Solutions ?
On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc
Re: Quad-A records in Network Solutions ?
On 3/28/2012 11:51 AM, Chris Adams wrote: Once upon a time, Lyndashr...@deaddrop.org said: This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. The same problem exists for DNSSEC; the number of registrars that support both IPv6 glue and DNSSEC in their standard interfaces is unfortunately small. True story, although Pairnic makes that one easy. I just wish they'd put up an automated interface for IPv6, but I'm happy they support it, at least. My favorite place to look for support for both is here: http://www.sixxs.net/faq/dns/?faq=ipv6glue No surprise to either of us that the column for DNSSEC is filled with yellow. :-( -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx
Re: BCP38 Deployment
In a message written on Wed, Mar 28, 2012 at 09:52:49AM -0700, Michael Thomas wrote: Yeahbut, the CPE isn't trusted. It would be _nice_ for customers to be bcp38 clueful as well, but I don't think it's _required_ for successful deployment from the ISP's standpoint. Even with a system like DOCSIS where the CPE is semi-trustworthy from a provisioning/etc standpoint, I don't think I'd _count_ on them. None of the routers are trusted if your perspective is right. It's easy to find a path like: Tier 1 ISP - Regional ISP - Local Provider - Subscriber - User Techologically it may look like: Tier 1 T640 core network with 10GE handoff Regional Cisco GSR network with 1GE handoff Local1006 to Arris CMTS Subscriber Motorola Cable Modem to NetGear SOHO Gateway User Patron with Airport Express sharing a wired connection to WiFi I don't trust any of the people in that list. More interesting from a BCP38 perspective who should be doing the filtering? If you were going to write it into law/regulation, where would you require it? Maybe all of them should, but can they from a technologial perspective? There's multi-homing in that chain somewhere. Do you require it at the first single homed place? If the subscriber is using a NetGear that does both ethernet and cell card backup and is thus multi-homed does that mean the user must do it? It's not even in my list, but re-asking my previous question why don't we go a step further and require the Operating System to do unicast RPF on-box? I think given the thorny set of issues that taking a step back and saying, rather than a perfect solution, what gets us most of the way there the cheapest, and quick is a good question to ask. I'm going to point to the local boxes. In my example the Netgear and Airport devices are in a posion to do super-cheap unicast RPF. They have (generally) one network behind them, and one way out. They are CPU based boxes for which this check requires no hardware changes. They don't even have enough interfaces in most cases to multi-home, so the chance of it breaking is nil. And yes, while the user may control both the end PC and these devices and thus be able to turn it off and circumvent all of this, that's really not the problem. The problem is infected machines spewing crap their owners don't know about, and just having a separate device upstream that stops it will do the job. The perfect is the enemy of the good in this case. Solving this at the consumer CPE level would remove 90-95% of the problem at zero hardware cost, a very small software cost, and a very small support cost and probably make us stop talking about this issue all together. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpAXUpJ4R4n0.pgp Description: PGP signature
Re: Quad-A records in Network Solutions ?
In a message written on Wed, Mar 28, 2012 at 01:51:19PM -0500, Chris Adams wrote: The same problem exists for DNSSEC; the number of registrars that support both IPv6 glue and DNSSEC in their standard interfaces is unfortunately small. joker.com supports both, and has a very nice web interface to do all the work. If your current provider doesn't support both you need to vote with your dollars. There are a dozen or more choices with good IPv6 and DNSSEC support. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpKJX66Be7J0.pgp Description: PGP signature
Re: Quad-A records in Network Solutions ?
I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc
Re: Quad-A records in Network Solutions ?
On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: BCP38 Deployment
On 03/28/2012 12:03 PM, Leo Bicknell wrote: None of the routers are trusted if your perspective is right. It's easy to find a path like: Tier 1 ISP - Regional ISP - Local Provider - Subscriber - User Techologically it may look like: Tier 1 T640 core network with 10GE handoff Regional Cisco GSR network with 1GE handoff Local1006 to Arris CMTS Subscriber Motorola Cable Modem to NetGear SOHO Gateway User Patron with Airport Express sharing a wired connection to WiFi I don't trust any of the people in that list. More interesting from a BCP38 perspective who should be doing the filtering? If you were going to write it into law/regulation, where would you require it? I wasn't talking about laws/regulation, just responding to your comment that lack of RPF in CPE was the bigger problem which doesn't seem right to me. If I'm the owner of the CMTS network, I really shouldn't be trusting the CM to be doing filtering for me. Maybe it would be nice to have RPF checks in the CM to nip a spoofed DDOS before it ever gets on the HFC network, but I wouldn't count on the CM not being compromised too, which means I should probably be running RPF on the aggregation router as well. Maybe all of them should, but can they from a technologial perspective? There's multi-homing in that chain somewhere. Do you require it at the first single homed place? If the subscriber is using a NetGear that does both ethernet and cell card backup and is thus multi-homed does that mean the user must do it? It's not even in my list, but re-asking my previous question why don't we go a step further and require the Operating System to do unicast RPF on-box? It's been a long time since I've read bcp 38, but I thought its intent was if you can reasonably do it, you *should* do it. multipath obviously makes RPF problematic, but the vast majority of the edge networks aren't multi-homed, so they really should be running RPF just as a matter of... best common practice. I think given the thorny set of issues that taking a step back and saying, rather than a perfect solution, what gets us most of the way there the cheapest, and quick is a good question to ask. I'm going to point to the local boxes. In my example the Netgear and Airport devices are in a posion to do super-cheap unicast RPF. They have (generally) one network behind them, and one way out. They are CPU based boxes for which this check requires no hardware changes. They don't even have enough interfaces in most cases to multi-home, so the chance of it breaking is nil. And yes, while the user may control both the end PC and these devices and thus be able to turn it off and circumvent all of this, that's really not the problem. The problem is infected machines spewing crap their owners don't know about, and just having a separate device upstream that stops it will do the job. The perfect is the enemy of the good in this case. Solving this at the consumer CPE level would remove 90-95% of the problem at zero hardware cost, a very small software cost, and a very small support cost and probably make us stop talking about this issue all together. Except for the small problem that getting cheap home router box manufacturers to do just about anything is a pushing on string exercise. So if I want to a) protect my network and b) be a good netizen, I'm still going to want to do BCP 38 regardless of whether others violate a, b or both. Right? Mike
Re: Quad-A records in Network Solutions ?
On Wed, Mar 28, 2012 at 04:13:53PM -0300, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc
Re: BCP38 Deployment
1. Give BCP38 the only practical anti-spoofing technique, can an ISP well protect its customers by implementing BCP38? I don't think so, because I think BCP38 is accurate near the source but inaccurate near the destination, i.e. if its customer is the target of spoofing attack, its capability to filter is relatively low. Nobody seems to have corrected this point. BCP38 is not intended to protect an ISP's customers. We're used to thinking in terms of protecting ourselves; you put locks on your front door or firewalls in front of your server. That's protecting yourself. If an ISP provides firewalling for their customers, then they are using it to protect the ISP's customers. BCP38 is intended to protect the *rest* of the Internet from *you* - or, more precisely, a bad guy who has taken over your connection. If your ISP implements BCP38, they are protecting everyone *else* from spoofed packets from your connection. It provides no protection for you, though. What provides protection for you is when *other* ISP's implement BCP38. If every other ISP except yours implemented BCP38, you'd be very well protected indeed. The problem here is that BCP38 assumes that service providers will work in the best interests of the Internet in general, implementing a filter that provides no measurable RoI for the SP. It's something that reduces everyone *else's* problems. It's good to implement on that basis, but most networks don't. ... 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.
Re: BCP38 Deployment
In a message written on Wed, Mar 28, 2012 at 12:44:04PM -0700, Michael Thomas wrote: Except for the small problem that getting cheap home router box manufacturers to do just about anything is a pushing on string exercise. So if I want to a) protect my network and b) be a good netizen, I'm still going to want to do BCP 38 regardless of whether others violate a, b or both. Right? BCP38 has nothing to do with a), doing it on your own network doesn't really protect you from much of anything of note. It's all about b), being a good citizen, and having a leg to stand on when you try to convince others to do the same which will help protect you. But the home router vendors aren't as hard to make move as you think. True, the chance of them moving in response to the fact that BCP38 exists, or that NANOG wants them to is zero. Nada, zilch. However, there are some powerful companies that buy a lot of boxes from these vendors. That free-to-the-subscriber box with a Comcast, Verizon, Cox, Cable Vision, ATT, SBC, or other provider label on it is just a rebranded version of one of these devices. If the guy buying several million dollars worth of the boxes showed up and demanded this feature, it would be done. Once it's done for them, it's a free feature they can market in the boxes at best-buy to try and recover more of their development costs. So in that sense we need to pressure the ISP's to implement BCP38! Maybe I'm back to agreeing with the OP! However we need to pressure them not to turn on RPF on their routers (although that's a fine thing too, defense in depth and all, if they can they should), but to pressure the vendors they are buying from to do it. The standards bodies should also be pressured as well, to get it into the specifications. I think some engineers need to ask some interesting questions, like how, in a box doing NAT to an outside IP, does it ever emit a packet not from that outside IP? The fact that you can spoof packets through some of the NAT implementations out there is mind-blowing to me. I'm telling you, if the big 10 ISP's would just add one bullet point to their RFP's for equipment: * Any device performing an IP routing function must default to strict mode unicast RPF for all connected networks as specified in RFC 3704 Section 2.2 as a method of implementing BCP38. We'd be done with this issue and move on to other things. Sure, there would still be spoofed packets, and yes, other types of operators (like free public wifi and such) still need to do the right BCP38 filtering when configuring their systems...but just having this on all residential gear gets rid of well over 90% of the crud we're all trying to stop. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpU4rJAS1z4t.pgp Description: PGP signature
Re: Quad-A records in Network Solutions ?
Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. I cannot take them as a serious provider for my names. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: BCP38 Deployment
On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote: Tier 1 T640 core network with 10GE handoff Regional Cisco GSR network with 1GE handoff Local1006 to Arris CMTS Subscriber Motorola Cable Modem to NetGear SOHO Gateway User Patron with Airport Express sharing a wired connection to WiFi ... If you were going to write it into law/regulation, where would you require it? Seems to me that from a legislator's perspective, there is a pretty bright (as in moth attracted to flame) line between subscriber and provider. Maybe all of them should, but can they from a technologial perspective? Implementing telephone number portability was probably technologically more challenging for the telcos to deal with but that didn't stop the legislators from requiring it. I think given the thorny set of issues that taking a step back and saying, rather than a perfect solution, what gets us most of the way there the cheapest, and quick is a good question to ask. You don't think that question has already been asked? It has been a dozen years since BCP38 was published. Over that period, the Internet has grown immensely and with it, the threats the ability to trivially spoofing source addresses represents. As far as I can tell, there has been little to no improvement in mechanisms to reduce those threats, yet high profile attacks against governments, departments/ministries, commercial organizations, etc., have only increased. I figure at some point (likely after a particularly high-profile attack), politicians and their corporate masters are going to feel the need to be seen to do something about the problem. I have some skepticism that 'something' is going to be an ideal solution. The perfect is the enemy of the good in this case. Solving this at the consumer CPE level would remove 90-95% of the problem at zero hardware cost, a very small software cost, and a very small support cost and probably make us stop talking about this issue all together. And the incentive for CPE manufacturers to invest in the small software cost is? Regards, -drc
Re: Quad-A records in Network Solutions ?
I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. Arturo Servin arturo.ser...@gmail.com wrote: Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. I cannot take them as a serious provider for my names. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: Quad-A records in Network Solutions ?
I am not taking about a big imaginary company. I am taking about NSI and this specific case. Regards, as On 29 Mar 2012, at 00:55, Joseph Snyder wrote: I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. Arturo Servin arturo.ser...@gmail.com wrote: Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. I cannot take them as a serious provider for my names. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: BCP38 Deployment
In a message written on Wed, Mar 28, 2012 at 02:49:02PM -0700, David Conrad wrote: On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote: Tier 1 T640 core network with 10GE handoff Regional Cisco GSR network with 1GE handoff Local1006 to Arris CMTS Subscriber Motorola Cable Modem to NetGear SOHO Gateway User Patron with Airport Express sharing a wired connection to WiFi ... If you were going to write it into law/regulation, where would you require it? Seems to me that from a legislator's perspective, there is a pretty bright (as in moth attracted to flame) line between subscriber and provider. The counterpoint I would offer is their are the most lobbiests and lawyers on the provider side of that equation, and indeed in the entire stack best I can tell. And the incentive for CPE manufacturers to invest in the small software cost is? The provders are large buyers of much of the CPE, and in some cases get to approve what CPE gets attached to their network. They can push this on the CPE manufacturers, and should. I suspect if legislators tried to push the issue their lobbiests and lawyers would attempt to stall and deflect, and that would be the direction. Many places already have laws that running an unsecured WiFi network is the subscriber's problem, not the providers. There's already operational and legal precident that the person running that end router should be responsible. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpEpDTpt1SWN.pgp Description: PGP signature
Re: Quad-A records in Network Solutions ?
On Mar 28, 2012 2:25 PM, Arturo Servin arturo.servinarturo.ser...@gmail.com @ arturo.ser...@gmail.comgmail.com arturo.ser...@gmail.com wrote: Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. I cannot take them as a serious provider for my names. Not having ipv6 and your website availability tied to some overloaded cgn at an ISP you have no relationship with or your abuse policy just blocked what you thought was a /24 ... turns out to be verizon nat44 space for nyc ... and now x million customers can't click buy now priceless. CB Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: Quad-A records in Network Solutions ?
Doesn't netsol charge something crazy like $50/year per for domain services? If that is still the case sounds like ipv6 support for 250k is a drop in the bucket :-). Not sure why any clueful DNS admin would still use netsol though. On Mar 28, 2012, at 5:55 PM, Joseph Snyder joseph.sny...@gmail.com wrote: I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. Arturo Servin arturo.ser...@gmail.com wrote: Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. I cannot take them as a serious provider for my names.. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John
Re: Quad-A records in Network Solutions ?
On Mar 28, 2012, at 3:13 PM, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos I absolutely agree with Carlos here this has got to be a joke or likelihood of NETSOL being extremely lazy on their part possibly lack of demand? There is absolutely no valid reason an update like this shouldn't be trivial to implement unless their system was built by IBM contractors :-) The core functionality of any IP/DNS management system is the flexibility and robustness to quickly add and remove address records. No matter how bad the system was designed or implemented not being able to support new record types is a complete FAIL on all counts especially from a veteran registrar like NETSOL. Like others have stated stick it where it hurts the most and use another vendor. On 3/28/12 3:55 PM, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc
Re: Quad-A records in Network Solutions ?
On Wed, Mar 28, 2012 at 11:55:35AM -0700, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc once, years ago, Netsol -did- have a path for injecting records. It was prototype code with the engineering team. I had records registered with them. Have since sold the domains and they moved to other registries. But they did support it for a while. /bill
Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc)
While I can't provide an average, I can say we generally have anywhere from 2-5 microwaves on most sites (with a few exceptions that only have 1, and a few that have more.) Our MWs go up to 1.6gbps. The sites aren't provisioned a set amount of bandwidth, they can use as much as they want (up to the capacity of the aggregate of their links), which almost never puts our BH anywhere near capacity, unless the ring gets cut near the pop and we have to move lots of data through just a couple of sites. (Sorry for the crappy formatting, small and barely usable phone screen.) Thanks! -Jacob On Mar 28, 2012 1:45 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Hi Nice discussion. Just a small question here - how much backhaul at present 2G, 3G and LTE based towers have? Just curious to hear an average number. I agree it would be a significant difference from busy street in New York to less crowded area say in Michigan but what sort of bandwidth telcos provision per tower? On fiber - I can imagine virtually unlimited bandwidth with incremental cost of optical instruments but how much to wireless backhaul based sites? Do they put Gigabit microwave everywhere? If not then say 100Mbps? If so then how end users on Verizon LTE people individual users get 10Mbps and so on? Is that operated at high contention? Thanks! (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 27, 2012 10:26 PM, Alexander Harrowell a.harrow...@gmail.com wrote: On Tue, Mar 27, 2012 at 1:45 AM, William Herrin b...@herrin.us wrote: On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard shadowedstrangerli...@gmail.com wrote: Who knows what technology will be like in 5-10 years? That's the whole point of what he was trying to say. Maybe wireless carriers will use visible wavelength lasers to recievers on top of customer's houses for all we know. 10 years is a LONG time for tech, and anything can happen. Regarding lasers. I agree that modulating a laser beam to carry information is a great idea. Perhaps, though, we could direct the beam down some sort of optical pipe or waveguide to spare ourselves the refractive losses and keep the pigeons and rain and whatnot out of the Fresnel zone. We might call it an optical wire or optical fibre or something. no, it'll never catch on... Hi Jacob, The scientists doing the basic research now know. It's referred to as the technology pipeline. When someone says, that's in the pipeline they mean that the basic science has been discovered to make something possible and now engineers are in the process of figuring out how to make it _viable_. The pipeline tends to be 5 to 10 years long, so basic science researchers are making the discoveries *now* which will be reflected in deployed technologies 10 years from now. I recall an Agilent Technologies presentation from a couple of years back that demonstrated that historically, the great majority of incremental capacity on cellular networks was accounted for by cell subdivision. Better air interfaces help, more spectrum helps, but as the maximum system throughput is roughly defined by (spectral efficiency * spectrum)* number of cells (assuming an even traffic distribution and no intercell interference or re-use overhead, for the sake of a finger exercise), nothing beats more cells. As a result, the Wireless Pony will only save you if you can find a 10GigE Backhaul Pony to service the extra cells. After a certain degree of density, you'd need almost as much fibre (and more to the point, trench mileage) to service a couple of small cells per street as you would to *pass the houses in the street with fibre*. One of the great things FTTH gets you is a really awesome backhaul network for us cell heads. One of the reasons we were able to roll out 3G in the first place was that DSL got deployed and you could provision on two or a dozen DSL lines for a cell site. You can't have wireless without backhaul (barring implausible discoveries in fundamental mesh network theory). Most wireless capacity comes from cell subdivision. Subdivision demands more backhaul. There is *nothing* promising in the pipeline for wireless tech that has any real chance of leading to a wide scale replacement for fiber optic cable. *Nothing.* Which means that in 10 years, wireless will be better, faster and cheaper but it won't have made significant inroads replacing fiber to the home and business. 20 years is a long time. 10 years, not so much. Even for the long times, we can find the future by examining the past. The duration of use of the predecessor technology (twisted pair) was about 50 years ubiquitously deployed to homes. From that we can make an educated guess about the current one (fiber). Fiber to the home started about 10 years ago leaving about 40 more before something
Re: BCP38 Deployment
On Wed, 28 Mar 2012 13:36:49 -0700, Leo Bicknell said: I think some engineers need to ask some interesting questions, like how, in a box doing NAT to an outside IP, does it ever emit a packet not from that outside IP? The fact that you can spoof packets through some of the NAT implementations out there is mind-blowing to me. The mind-blowing part for me: Look at the MIT spoofing website, at what percent of the net's address space is spoofable. Then consider what percent of the net is behind a NAT (either consumer grade, or enterprise NAT). http://spoofer.csail.mit.edu/summary.php They're reporting that 20% or so (eyeballing) is unable to spoof due to a NAT. From that, and a guess of what % is *really* behind a NAT, we can make an estimate of how common this failure mode is. pgpYsyFffcuPX.pgp Description: PGP signature
