Re: Dynamic (changing) IPv6 prefix delegation
Nathan Eisenberg nat...@atlasnetworks.us writes: What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? What does Joe's ISPack save the missing bits for? Bjørn
Re: Dynamic (changing) IPv6 prefix delegation
On Monday 21 Nov 2011 20:27:55 Owen DeLong wrote: I suspect that mDNS/Rendezvous will become much more widespread in the IPv6 household and will become the primary service discovery mechanism. It actually works quite well and is relatively resilient to either frequent renumbering or the ill-advised use of ULA. A while ago there was some discussion of wouldn't mDNS/Rendezvous/Bonjour that doesn't suck be nice? on the list. I for one agree with Owen that it's important for a whole lot of things and will get more so in trying to deliver the promises of IPv6. (If you want network everywhere you probably need zero-configuration everywhere, and the network that's everywhere is IP.) I also think it's an underestimated contribution to the success of Apple in the iDevice era, much as network people tend to hate it. So perhaps we could identify what it is about mDNS service discovery that we hate and what could be improved. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
Re: Looking for a Tier 1 ISP Mentor for career advice.
Scott's point is very true! Motivation will help you go very far, much farther than certs/knowledge alone. As a soon to be college-grad, be ready for the initial disappointment, :-), even though you'll have your CCNP, you have no real experience, so you'll start at the entry level. That's not a bad thing, but you might see it as such. The reason it is good, is that while at the entry level (networking that is, I'm not talking about a helpdesk), you'll get to touch and interact with a lot of different things with very little total responsibility. As you impress your peers, this will trickle up towards management, and eventually work it's way out into better tasks and larger responsibilities (try to not get caught up in the title). I'm speaking from experience here, I'm a senior network engineer for a $2 B company, yet only 25 years old, currently working on my R/S CCIE purely for the learning experience. It took me nearly 4 years to move from an associate to a senior in my company, which is not common in that short of a time-frame for my employer, but that's where the motivation piece comes in -- expressing true passion, and learning things because they are cool/interest you will take you far. Learning on paper is what you're taught in college and it only works so far, but learning from hand-on, like the lab you've got built, is where you attain the knowledge/troubleshooting/experience that will help you succeed. A comment earlier in the thread mentioned should I learn active directory/exchange? I hear this a lot from our fellow associate's on the team and to be honest, if you are learning something just to add it to your resume, that will be a waste of your time. But, if you are learning it because you find it interesting or just want to explore, then by all means go deep into it. I personally go by the motto go full in or don't go at all. So if I'm going to learn something, I'll get as deep as I can into it, and focus on just it for a little while, then I'll move to something else, and focus on just that. If you try to focus on too many separate things, you'll become this odd ball of knowledge that can't really hold you own -- a tip in the industry that will get you far: be able to take ownership, and fully run/own what you're working on. Regardless of level/title/role, a person who takes initive (within the scope/dynamic of their position), will go far. Best of luck to you, David. On Mon, Nov 21, 2011 at 5:32 PM, Scott Weeks sur...@mauigateway.com wrote: --- tyler.ha...@gmail.com wrote: From: Tyler Haske tyler.ha...@gmail.com I'd love to have varied experience with a bunch of different companies, but first I'm trying to guarantee my first network engineering job out of college. --- You've already taken the first step. That step being you becoming more motivated than many of the other soon-to-be-graduates around you. This motivation will carry you a long way in your career. Who knows, you may be applying to someone here on this list one day... scott
Re: First real-world SCADA attack in US
On Mon, 21 Nov 2011 14:24:48 PST, andrew.wallace said: If NSA had no signals information prior to the attack, this should be a wake up call for the industry. Actually, it should be a wake up call whether or not NSA had signals information. However, it's pretty obvious that the entire SCADA segment is pretty much bound and determined to keep hitting the snooze button as long as possible - they've known they have an endemic security problem just about the same number of years the telecom segment has known they will need to deploy IPv6. ;) And let's think about this for a moment - given that there's *no* indication that the attack was an organized effort from a known group, and could quite possibly be just a bored 12 year old in Toledo Ohio, why should the NSA have any signals info before the attack? Let's think it through a bit more. Even if the NSA *did* have info beforehand that pointed at a kid in Toledo, they can't easily release that info before the fact, for several reasons: (a) they're not supposed to be surveillancing US citizens, so having intel on a kid in Toledo would be embarassing at the least, and (b) revealing they have the intel would almost certainly leak out the details of where, when, and how they got said info - and the NSA would almost certainly be willing to sacrifice somebody else's water pump rather than reveal how they got the info. Bottom line - the fact the NSA didn't say something beforehand means that they either didn't know, or didn't wish to tell. So why are you bringing the NSA into it? pgpehPx2T9Xf4.pgp Description: PGP signature
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote: Precisely. THe case in point example these days is traffic light controllers. I know from traffic light controllers; when I was a kid, that was my dad's beat for the City of Boston. Being a geeky kid, I drilled the guys in the signal shop, the few times I got to go there (Saturdays, and such). The old design for traffic signal controllers was that the relays that drove each signal/group were electrically interlocked: the relay that made N/S able to engage it's greens *got its power from* the relay that made E/W red; if there wasn't a red there, you *couldn't* make the other direction green. These days, I'm not sure that's still true: I can *see* the signal change propagate across a row of 5 LED signals from one end to the other. Since I don't think the speed of electricity is slow enough to do that (it's probably on the order of 5ms light to light), I have to assume that it's processor delay as the processor runs a display list to turn on output transistors that drive the LED light heads. That implies to me that it is *physically* possible to get opposing greens (which we refer to, in technical terms as traffic fatalities) out of the controller box... in exactly the same way that it didn't used to be. That's unsettling enough that I'm going to go hunt down a signal mechanic and ask. The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. -- Brett
Re: Dynamic (changing) IPv6 prefix delegation
On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos seth@dds.nl wrote: What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. I often hear if you need a static IP, you need business class server; bundled with we don't provide business service to residential customers. Almost makes one think there ought to be some consumer protection laws regulating it. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: First real-world SCADA attack in US
- Original Message - From: Brett Frankenberger rbf+na...@panix.com The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. ... assuming the *conflict monitor* hasn't itself failed. There, FTFY. Moron designers. 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: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 10:16:56AM -0500, Jay Ashworth wrote: - Original Message - From: Brett Frankenberger rbf+na...@panix.com The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. ... assuming the *conflict monitor* hasn't itself failed. There, FTFY. Moron designers. Yes, but then you're two failures deep -- you need a controller failure, in a manner that creates an unsafe condition, followed by a failure of the conflict monitor. Lots of systems are vulnerable to multiple failure conditions. Relays can have interesting failure modes also. You can only protect for so many failures deep. -- Brett
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. Break the internet is about how I'd phrase it. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). 8) Don't use the wrong ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination.
Any recommended router. They are reliable and have good support.
Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Lossy compression HTTP proxy
Hello, I am looking for a proprietary $subj, a la ziproxy [1]. Caching is not the main concern (well, I wouldn't mind it caching compressed JPEGs). Mobile telco people should probably know a few vendors. Thanks! [1] http://ziproxy.sourceforge.net -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com
Re: Any recommended router. They are reliable and have good support.
Brocade have some reasonable boxes. -- Leigh Porter On 22 Nov 2011, at 15:40, Deric Kwok deric.kwok2...@gmail.com wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Any recommended router. They are reliable and have good support.
On 11/22/2011 3:38 PM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you http://www.vyatta.com/ might be worth checking.
Re: Any recommended router. They are reliable and have good support.
http://imagestream.com On 11/22/11 9:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Re: Any recommended router. They are reliable and have good support.
mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Re: Dynamic (changing) IPv6 prefix delegation
Hello, On 11/21/11 16:21, Seth Mos wrote: Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? I think it should be to option for the end users. Select if they want stable IPv6 prefix or random IPv6 prefix. One of the thoughts that came to mind is T-Online in Germany that still disconnects it's (PPPoE) user base every 24 hours for a new random IP. This is kind of solution for preserving IPv4 addresses. Side effect of the changing IP address is that user can be tracked back if ISP is logging the actual IP binding. Short of setting really short timers on the RA messages for the LAN I can see a multitude of complications for consumers in the long run. People that configure their NAS, Media Player and Printer on their own network. And using ULA for either is not workable unless they somehow manage to grow DNS skill on the end user. Their NAS probably wants to download from the 'net and access videos from the NAS. The media player wants to be able to access youtube and the laptop needs to (reliably) find it's printer each time. I really hope that ISPs will commit to assigning the same prefix to the same user on each successive connection. Agree. Kind Regards, Janos Mohacsi
Re: Any recommended router. They are reliable and have good support.
Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Any recommended router. They are reliable and have good support.
+1 MikroTik http://www.mikrotik.com - Original Message - From: Deric Kwok deric.kwok2...@gmail.com To: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 5:38 PM Subject: Any recommended router. They are reliable and have good support. Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Any recommended router. They are reliable and have good support.
Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: fai...@snappydsl.net Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Any recommended router. They are reliable and have good support.
I have used quite a few of their devices and have been impressed. The bang for your buck is unlike anything else. I sometimes wonder why I bother buying other kit, apart from the larger boxes. Maybe I'll find a bug and test them out ;-) -- Leigh On 22 Nov 2011, at 16:04, Meftah Tayeb tayeb.mef...@gmail.com wrote: Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: fai...@snappydsl.net Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Dynamic (changing) IPv6 prefix delegation
Worst case, you can always get an IPv6 static /48 from at least one provider without any additional cost. Owen On Nov 22, 2011, at 7:05 AM, Ray Soucy wrote: On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos seth@dds.nl wrote: What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. I often hear if you need a static IP, you need business class server; bundled with we don't provide business service to residential customers. Almost makes one think there ought to be some consumer protection laws regulating it. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dynamic (changing) IPv6 prefix delegation
snip On 22 Nov 2011, at 13:38, Joel Maslak wrote: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). snip Add to your list: 1.5) Instead of getting IPv6, getting private IPv4 and CGN service. -as
OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
- Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. The perceived risk in this case is multiple high-speed traffic fatalities. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. -- 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: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I like being able to reach things in my house when I'm on the road. Having the prefix not bounce around turns out to be convenient for that. I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. That's beyond tragic if it's actually true. You should name and shame your provider if that's really the case. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). I haven't run into too many of these in the real world any more other than actual tiered services where you have the option of buying a higher bandwidth service. What I mostly see these days is hard-limits on negotiated speed of the connection. 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. Break the internet is about how I'd phrase it. The app would never become popular because most people would be unable to use it. It wouldn't break the internet. The internet would break the app. in its current state. Whether either of those possibilities is good or bad is left as an exercise for the reader. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). Mostly it means that your provider sort of gets IPv6, but, not really. If you want to provide me with contact information off-list, I'll attempt to engage in an educational outreach. 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. Yes, sounds like your provider needs to be hit with a clue-by-four. I don't think that typifies the rest of the world, though it's not as uncommon as I would like, either. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). Yes, this is an increasingly common problem. Thanks, Micr0$0ft. 8) Don't use the wrong ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. Huh? I haven't seen this problem at all. I've seen packets arrive with the ToS bits stripped, but, I haven't seen ToS cause a packet to get dropped. You seem to have found a particularly bleak set of providers to use. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination. I expect my packets to get delivered (and they generally do) and I have static addresses too. You can have it all if you try. Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? pgpRef9eoBJEx.pgp Description: PGP signature
Re: Dynamic (changing) IPv6 prefix delegation
3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. I've come across a non-zero number of residential providers, who, with or without NAT, explicitly discard protocols 50 and 51. The same argument is applied - if you want this, you must buy a business connection. Which is usually double-speak for add an order of magnitude to the price, turn off *some* of the broken-ness. Regards, Tim.
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, Nov 22, 2011 at 11:36 AM, valdis.kletni...@vt.edu wrote: A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? This. My options for home are Time Warner Cable 15M down, 1M up; or Fairpoint DSL, 3M down, 128K up. So my option is really only TWC. And I live 3 miles off the University of Maine campus. Other parts of the state don't have the luxury of more than one option, if any. You can't vote with your wallet if you're stuck with a monopoly. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:36 AM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? I didn't say they wouldn't make money... I said they wouldn't make MORE money. Owen
RES: Any recommended router. They are reliable and have good support.
On 22/11/2011 1:39pm, Deric Kwok wrote: Can I know any selection of Linux routers except cisco / juniper? I prefer Freebsd. Take a look on BSDRP (BSD Route Project). http://bsdrp.net/ -- Eduardo Schoedler
Re: Any recommended router. They are reliable and have good support.
Imagestream is *nix based and has excellent customer service. -- Justin Wilson j...@mtin.net Aol Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.twitter.com/j2sw Follow me on Twitter -Original Message- From: Meftah Tayeb tayeb.mef...@gmail.com Date: Mon, 21 Nov 2011 16:24:24 +0200 To: Deric Kwok deric.kwok2...@gmail.com, nanog list nanog@nanog.org Subject: Re: Any recommended router. They are reliable and have good support. +1 MikroTik http://www.mikrotik.com - Original Message - From: Deric Kwok deric.kwok2...@gmail.com To: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 5:38 PM Subject: Any recommended router. They are reliable and have good support. Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RES: Any recommended router. They are reliable and have good support.
One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler -Mensagem original- De: Meftah Tayeb [mailto:tayeb.mef...@gmail.com] Enviada em: segunda-feira, 21 de novembro de 2011 12:26 Para: Leigh Porter; fai...@snappydsl.net Cc: nanog list Assunto: Re: Any recommended router. They are reliable and have good support. Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: fai...@snappydsl.net Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Re: Any recommended router. They are reliable and have good support.
Le Tue, 22 Nov 2011 14:59:13 -0200, Eduardo Schoedler lis...@esds.com.br a écrit : On 22/11/2011 1:39pm, Deric Kwok wrote: Can I know any selection of Linux routers except cisco / juniper? I prefer Freebsd. Take a look on BSDRP (BSD Route Project). http://bsdrp.net/ The problem with this is to find good hardware for it, that is affordable, robust, and does not uses the power of a desktop pc. -- Eduardo Schoedler
RES: Any recommended router. They are reliable and have good support.
On 22/11/2011 3:06pm, Julien Gormotte wrote: Le Tue, 22 Nov 2011 14:59:13 -0200, Eduardo Schoedler lis...@esds.com.br a écrit : On 22/11/2011 1:39pm, Deric Kwok wrote: Can I know any selection of Linux routers except cisco / juniper? I prefer Freebsd. Take a look on BSDRP (BSD Route Project). http://bsdrp.net/ The problem with this is to find good hardware for it, that is affordable, robust, and does not uses the power of a desktop pc. I agree, but with Intel hardware, that's not a problem. -- Eduardo Schoedler
Re: Any recommended router. They are reliable and have good support.
On Tue, Nov 22, 2011 at 10:43 AM, lorddoskias lorddosk...@gmail.com wrote: On 11/22/2011 3:38 PM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you http://www.vyatta.com/ might be worth checking. If you are not afraid of the command line check xorp it is what vyatta is based on.
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:19 AM, Owen DeLong wrote:
Exactly. ISPs are in business to make as much money as they can - go figure.
How do you make more money by refusing to meet customer requests?
Not rocket science. The vast majority of customers fall into a small number of
categories. You make money by optimizing for those categories. For the folks
that don't fit in those categories (e.g., people who actually ask for IPv6),
you treat them as special cases until there are sufficient requests to justify
a new category.
1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years
or so when the equipment my line on is old enough to be replaced under a 15
or 20 year replacement cycle.
That's beyond tragic if it's actually true. You should name and shame your
provider if that's really the case.
I suspect most (all?) very large scale service providers amortize their
equipment over quite long periods. If said equipment doesn't support
feature, it becomes a relatively simple cost/benefit analysis to determine
whether or not upgrading the hardware out of cycle would have sufficient ROI to
justify the cost. A lot depends on how many customers will bolt if feature
isn't offered before the equipment is put out to pasture naturally. Since
(currently) the vast majority of large scale providers' customers have no
interest in (or even knowledge of) IPv6, it's unlikely the cost/benefit
analysis ends up in a pro-IPv6 way.
There are, of course, more forward looking ISPs, but they appear to be the
exception rather than the rule.
3) If you write an application using anything other than UDP or TCP, it
won't work on most networks (with some minor exceptions for PPTP and IPSEC,
which work sometimes).
This hasn't been my experience unless you're behind some form of NAT. Yes, it
is well known that NAT breaks most protocols.
Not NAT. Default deny firewalls. Look at the recommended firewall configs
from pretty much any security consultant/vendor and see what happens when you
try to turn on (say) SCTP.
4) What would happen if someone wrote a popular app that used IP options? I
don't want to know that answer even though I already know it. Break the
internet is about how I'd phrase it.
The app would never become popular because most people would be unable to use
it.
Right. See 'default deny firewalls'.
6) The same server can't receive IP fragments, except for the first one.
For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6
will cause longer answers). Yes, I know I can turn off large UDP responses
on my resolver. I bet more than a few people don't know that though.
I believe at least one resolver (BIND) will do this for you. It first tries
using an extension that allows for a 4096-byte buffer. If that fails, it tries
using the extension with a 512-byte buffer. If that fails, it turns off the
extension. In the latter 2 cases, if the response is larger than 512 bytes, DNS
will automatically fall back to TCP. Increases latency, but that's life on the
Real Internet(tm).
7) Even UDP and TCP aren't going to work everywhere. Hense why everything
seems to tunnel over HTTP or HTTPS even when that's an inappropriate method
(such as when reliable ordered packet delivery is a hinderence).
Yes, this is an increasingly common problem. Thanks, Micr0$0ft.
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the
real IPng.
Regards,
-drc
Re: Any recommended router. They are reliable and have good support.
On Nov 22, 2011, at 9:09 AM, James Jones wrote: On Tue, Nov 22, 2011 at 10:43 AM, lorddoskias lorddosk...@gmail.com wrote: On 11/22/2011 3:38 PM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you http://www.vyatta.com/ might be worth checking. If you are not afraid of the command line check xorp it is what vyatta is based on. Vyatta uses Quagga for the protocol stack. We switched away from XORP a few years ago. Cheers, Robert.
Re: Looking for a Tier 1 ISP Mentor for career advice.
On Mon, Nov 21, 2011 at 2:12 PM, Keegan Holley keegan.hol...@sungard.com wrote: 2011/11/21 valdis.kletni...@vt.edu On Sun, 20 Nov 2011 21:40:08 EST, Tyler Haske said: I'm looking for a mentor who can help me focus my career so eventually I wind up working at one of the Tier I ISPs as a senior tech. I want to handle the big pipes that hold everyone's data. ... I'd say their ultimate goal is to touch a little as possible which is usually as unglamorous as it sounds. Also, alot of things are scripted so much of what you touch may not be as fun. Tyler, this is absolutely key, and absolutely true; if you really, really want to get a jump in the industry, don't worry about learning active directory or exchange (unless it's a particular hobby interest of yours); instead, learn a good scripting language; PERL is the canonical example, but python or tcl are equally fine candidates these days. Most of the really big networks, whether access ISPs, content providers, or tier 1 transit networks try to automate as much of the work as possible; it's the only way to stay ahead of the demand curve. If you want to be a hot property in networking, you should have a good blend of network skills, scripting/development skills, and ideally enough system administration background to know how to make the boxes running those tools happy as well. Being able to understand the packet flow from the application, down through the OS, and onto the wire, and then back up again at the far end is going to make you much more useful than an engineer that just knows how to get bits from point A to point Z, but that's it. Being able to turn up a 100GE link by hand is useful; but being able to write a script to turn up dozens at a time--that's what networks will fight over to get. (Also...echoing an undercurrent from several of the other voices...set up an account on tunnelbroker.net, get a v6 tunnel going to your house, set up a linux box with your favorite flavour of DNS server on it; start learning how to handle v6 DNS zones, the odd and occasional challenges involved with dual-stacked hosts and different DNS entries. And then start experimenting and breaking things--some of your best understanding is going to come from breaking your setup when experimenting, and then figuring out why it broke, and how to get it working again in the way you want. Debugging dual-stack networks is going to be required knowledge by the time you hit the industry; no reason not to start learning and using the information today, to really get comfortable with it.) You'll find that many of us are happy to answer intelligent, well-thought-through questions; what we don't tend to like are answering questions that are easily found through quick search engine queries. If you've done your own exploration first, and come up empty, chances are it'll be an interesting enough question someone out here will be willing to give a shot at answering it for you. But if you ask questions that would be just as easily answered through spending 5 minutes with a search engine, you'll find even the best mentors will start to give you the cold shoulder. ^_^; And finally...don't get discouraged; if you're pretty sure this is what you want to do with your life, stick with it. There can be some big ups and downs in this industry, but the chance to build something really big that touches millions of lives every day brings with it that huge sense of accomplishment that only comes with achieving something on a truly global scale. Best of luck! Matt
Re: Dynamic (changing) IPv6 prefix delegation
Owen DeLong o...@delong.com naively wrote: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? By 'encouraging' those 'high cost / low profit' customers to 'go elsewhere', and devoting the resources that they would otherwise consume to supporting 'lower-cost/ higher-profit' customers. This is 'no-brainer' free-market economics. :)
RES: Any recommended router. They are reliable and have good support.
One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler -Mensagem original- De: Eduardo Schoedler [mailto:lis...@esds.com.br] Enviada em: terça-feira, 22 de novembro de 2011 15:04 Para: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Assunto: RES: Any recommended router. They are reliable and have good support. One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler -Mensagem original- De: Meftah Tayeb [mailto:tayeb.mef...@gmail.com] Enviada em: segunda-feira, 21 de novembro de 2011 12:26 Para: Leigh Porter; fai...@snappydsl.net Cc: nanog list Assunto: Re: Any recommended router. They are reliable and have good support. Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: fai...@snappydsl.net Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Re: Dynamic (changing) IPv6 prefix delegation
3) If you write an application using anything other than UDP or TCP, it
won't work on most networks (with some minor exceptions for PPTP and IPSEC,
which work sometimes).
This hasn't been my experience unless you're behind some form of NAT. Yes,
it is well known that NAT breaks most protocols.
Not NAT. Default deny firewalls. Look at the recommended firewall configs
from pretty much any security consultant/vendor and see what happens when you
try to turn on (say) SCTP.
No, NAT. Yes, default deny firewalls can add additional breakage, but, even if
you add the requisite permits in many cases NAT will still break most things
for which ALGs haven't been provided in the NAT box. Default deny firewalls are
a configuration problem that can be easily addressed through configuration. NAT
is a fundamental damage to network services which requires modifying the actual
NAT device or its firmware to work around or the elimination of NAT to resolve.
7) Even UDP and TCP aren't going to work everywhere. Hense why everything
seems to tunnel over HTTP or HTTPS even when that's an inappropriate method
(such as when reliable ordered packet delivery is a hinderence).
Yes, this is an increasingly common problem. Thanks, Micr0$0ft.
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to enable/encourage
this trend?
Owen
RE: Any recommended router. They are reliable and have good support.
I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, I will configure a new router/AP/whatever Mikrotik device and it simply will not work. The config is correct, but the device just won't work properly (sometimes it won't pass data, it won't bridge correctly, VLAN membership isn't correct, etc). However, if I reset the device to factory settings (Which takes forever because you have to find the little metal half circles and use a flat-head screwdriver to bridge them) and redo the EXACT same config everything will magically work. This annoyance hasn't been enough to make me switch to another brand yet, but I know every time I have to deploy a new device I'm likely to wrestle this issue. --Thomas York -Original Message- From: Eduardo Schoedler [mailto:lis...@esds.com.br] Sent: Tuesday, November 22, 2011 1:00 PM To: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Subject: RES: Any recommended router. They are reliable and have good support. One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler -Mensagem original- De: Eduardo Schoedler [mailto:lis...@esds.com.br] Enviada em: terça-feira, 22 de novembro de 2011 15:04 Para: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Assunto: RES: Any recommended router. They are reliable and have good support. One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler -Mensagem original- De: Meftah Tayeb [mailto:tayeb.mef...@gmail.com] Enviada em: segunda-feira, 21 de novembro de 2011 12:26 Para: Leigh Porter; fai...@snappydsl.net Cc: nanog list Assunto: Re: Any recommended router. They are reliable and have good support. Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porter leigh.por...@ukbroadband.com To: fai...@snappydsl.net Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiaz fai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you smime.p7s Description: S/MIME cryptographic signature
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On Tue, Nov 22, 2011 at 11:16:54AM -0500, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. Relay logic has the potential for programming (i.e. wiring) errors also. It's not fair to compare conflict monitor to properly programmed relay logic. We either have to include the risk of programming failures (which means improper wiring in the case of relay logic) in both cases, or exclude programming failures in both cases. The perceived risk in this case is multiple high-speed traffic fatalities. Some of the benefits of the newer systems are safety related also. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. And, yes, convenience is also an objective. Most people wouldn't want to live in a city where the throughput benefit of modern traffic signalling weren't available, even if they have to accept a very, very small increase in risk. -- Brett
Re: Any recommended router. They are reliable and have good support.
Having worked with approx 10-15 units of RouterBoards, I cannot say that I have see this issue. Could it be some sort of a software bug ? we typically update the mikrotik OS and Firmware before we deploy. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 1:58 PM, Thomas York wrote: I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, I will configure a new router/AP/whatever Mikrotik device and it simply will not work. The config is correct, but the device just won't work properly (sometimes it won't pass data, it won't bridge correctly, VLAN membership isn't correct, etc). However, if I reset the device to factory settings (Which takes forever because you have to find the little metal half circles and use a flat-head screwdriver to bridge them) and redo the EXACT same config everything will magically work. This annoyance hasn't been enough to make me switch to another brand yet, but I know every time I have to deploy a new device I'm likely to wrestle this issue. --Thomas York -Original Message- From: Eduardo Schoedler [mailto:lis...@esds.com.br] Sent: Tuesday, November 22, 2011 1:00 PM To: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Subject: RES: Any recommended router. They are reliable and have good support. One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler -Mensagem original- De: Eduardo Schoedler [mailto:lis...@esds.com.br] Enviada em: terça-feira, 22 de novembro de 2011 15:04 Para: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Assunto: RES: Any recommended router. They are reliable and have good support. One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler -Mensagem original- De: Meftah Tayeb [mailto:tayeb.mef...@gmail.com] Enviada em: segunda-feira, 21 de novembro de 2011 12:26 Para: Leigh Porter; fai...@snappydsl.net Cc: nanog list Assunto: Re: Any recommended router. They are reliable and have good support. Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porterleigh.por...@ukbroadband.com To:fai...@snappydsl.net Cc: nanog listnanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiazfai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Relay logic has the potential for programming (i.e. wiring) errors also. Yes, but the complexity of a computerized controller is 3-6 orders of magnitude higher, *and none of it is visible* It's not fair to compare conflict monitor to properly programmed relay logic. We either have to include the risk of programming failures (which means improper wiring in the case of relay logic) in both cases, or exclude programming failures in both cases. See above, and note that there are at least a couple orders of magnitude more possible failure modes on a computerized controller as well. Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, My understanding was that it was completely impossible. You could fail dark, but you *could not* fail crossing-green. but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is a dark traffic signal is a 4-way stop. but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think new Coke. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Sure. But we have no numbers on either side. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. See above about whether people trust green lights to be safe. And, yes, convenience is also an objective. Most people wouldn't want to live in a city where the throughput benefit of modern traffic signalling weren't available, even if they have to accept a very, very small increase in risk. Assuming they knew they were accepting it. But if it amounts to Well, it's going to cost you more if we do it [right], well, look out for #OccupyMainStreet. We can fake it cause it's cheaper is pretty close to a dead approach, I suspect. 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
automated config backups for SFTOS
Does anyone know of a method of automating config backups for force10 switches running SFTOS ? I've got an python expect script that works on our routers running FTOS, it uses a role account that can show the running configs without having to use the enable password. i could expand the script to use the enable password but i'm hesitant to have it lying around in a script Jon Heise
Re: automated config backups for SFTOS
Deploy RANCID? On Tue, Nov 22, 2011 at 1:35 PM, Jon Heise j...@smugmug.com wrote: Does anyone know of a method of automating config backups for force10 switches running SFTOS ? I've got an python expect script that works on our routers running FTOS, it uses a role account that can show the running configs without having to use the enable password. i could expand the script to use the enable password but i'm hesitant to have it lying around in a script Jon Heise -- Jason
Re: Any recommended router. They are reliable and have good support.
+1 Faisal never has any kind of issue with RouterBoards :) Faisal, please contact me offlist - Original Message - From: Faisal Imtiaz fai...@snappydsl.net To: Thomas York strate...@fuhell.com Cc: lis...@esds.com.br; tayeb.mef...@gmail.com; leigh.por...@ukbroadband.com; nanog@nanog.org Sent: Tuesday, November 22, 2011 9:19 PM Subject: Re: Any recommended router. They are reliable and have good support. Having worked with approx 10-15 units of RouterBoards, I cannot say that I have see this issue. Could it be some sort of a software bug ? we typically update the mikrotik OS and Firmware before we deploy. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 1:58 PM, Thomas York wrote: I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, I will configure a new router/AP/whatever Mikrotik device and it simply will not work. The config is correct, but the device just won't work properly (sometimes it won't pass data, it won't bridge correctly, VLAN membership isn't correct, etc). However, if I reset the device to factory settings (Which takes forever because you have to find the little metal half circles and use a flat-head screwdriver to bridge them) and redo the EXACT same config everything will magically work. This annoyance hasn't been enough to make me switch to another brand yet, but I know every time I have to deploy a new device I'm likely to wrestle this issue. --Thomas York -Original Message- From: Eduardo Schoedler [mailto:lis...@esds.com.br] Sent: Tuesday, November 22, 2011 1:00 PM To: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Subject: RES: Any recommended router. They are reliable and have good support. One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler -Mensagem original- De: Eduardo Schoedler [mailto:lis...@esds.com.br] Enviada em: terça-feira, 22 de novembro de 2011 15:04 Para: 'Meftah Tayeb'; 'Leigh Porter'; fai...@snappydsl.net Cc: 'nanog list' Assunto: RES: Any recommended router. They are reliable and have good support. One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler -Mensagem original- De: Meftah Tayeb [mailto:tayeb.mef...@gmail.com] Enviada em: segunda-feira, 21 de novembro de 2011 12:26 Para: Leigh Porter; fai...@snappydsl.net Cc: nanog list Assunto: Re: Any recommended router. They are reliable and have good support. Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you - Original Message - From: Leigh Porterleigh.por...@ukbroadband.com To:fai...@snappydsl.net Cc: nanog listnanog@nanog.org Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, Faisal Imtiazfai...@snappydsl.net wrote: mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you __ Information from ESET NOD32 Antivirus, version of virus signature database 6652 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6652 (2022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Any recommended router. They are reliable and have good support.
Leigh Porter leigh.por...@ukbroadband.com writes: Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? I have dealt with Mikrotik support. They were easily comparable to [CJ]TAC. Which is to say guy was pleasant and courteous, I could tell through the language barrier that he wasn't really interested in addressing my problems or understanding them, and eventually I got exasperated and figured out a work-around. That said, it's easy to exceed expectations when you've spent something like $70 on a router that does five ports of gigabit ethernet. Several dot releases after that little ordeal, at least one of my laundry list of problems (ssh connections blew up if you are using application layer keepalives) seems to have gotten fixed, at least in 5.8, with nary a mention in the release notes so I assume it was a matter of syncing the codebase to whatever they run for an ssh server. Still no fix for the your CLI only partially implements Emacs key binds, please try libcli.a which is LGPL instead, which is annoying since this shortcoming is really up in your grill whenever you're logged into the router. Still can't traceroute to an IPv6 host by name, only by number. Dunno if they figured out what the G in GRE stands for yet and started allowing protocols other than IPv4 (and ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to test it out since I managed to get 6in4 tunneling working instead. There are more random gripes, but you get the idea - routeros definitely shows a certain lack of polish but can get the job done for low-end stuff at a very acceptably low-end price. All in all, despite the gripes it's worth your time to check out. Don't let the folks who sing their praises get your hopes up too much but hey, for pocket change invested? Pretty decent. There are some good surprises in there too, like putative support for 32 bit ASNs (haven't tested that myself) and scriptability that will allow you to send TSIG-signed dns update messages periodically for when you have customers to support that are on the far end of a non-sticky DHCP. -r
Re: Any recommended router. They are reliable and have good support.
We use a lot of Mikrotik in our network. They are fantastic little routers as long as you remember that they are not Cisco/Juniper/whatever. In other words, you pay a few hundred bucks, you get something worth at least that much. But don't put it head to head against a $10k router. Support is technically sound, but you have to email Latvia and then wait for the time difference to get a response. If you expect to pay $100 for a router and then get prompt, courteous, 24/7 tech support, you will be disappointed. :) We use their routers mostly for end user gateways doing QOS. They do a superb job of this. I wouldn't particularly want them as network edge devices or core routers; they will choke up if the PPS rate gets too high and you are doing any kind of packet mangling. There have been a lot of bugs in various versions of RouterOS, but the current (5.8?) OS seems pretty good. They added IPv6 support and fixed a ton of bugs. OSPF implementation was buggy before OS5, but seems to be relatively stable since we upgraded. BGP works fine but is perhaps less feature rich than Cisco/Zebra. Joseph Alyrica Networks Inc / www.alyrica.net - Original Message - From: Robert E. Seastrom r...@seastrom.com To: Leigh Porter leigh.por...@ukbroadband.com Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 11:52 AM Subject: Re: Any recommended router. They are reliable and have good support. Leigh Porter leigh.por...@ukbroadband.com writes: Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? I have dealt with Mikrotik support. They were easily comparable to [CJ]TAC. Which is to say guy was pleasant and courteous, I could tell through the language barrier that he wasn't really interested in addressing my problems or understanding them, and eventually I got exasperated and figured out a work-around. That said, it's easy to exceed expectations when you've spent something like $70 on a router that does five ports of gigabit ethernet. Several dot releases after that little ordeal, at least one of my laundry list of problems (ssh connections blew up if you are using application layer keepalives) seems to have gotten fixed, at least in 5.8, with nary a mention in the release notes so I assume it was a matter of syncing the codebase to whatever they run for an ssh server. Still no fix for the your CLI only partially implements Emacs key binds, please try libcli.a which is LGPL instead, which is annoying since this shortcoming is really up in your grill whenever you're logged into the router. Still can't traceroute to an IPv6 host by name, only by number. Dunno if they figured out what the G in GRE stands for yet and started allowing protocols other than IPv4 (and ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to test it out since I managed to get 6in4 tunneling working instead. There are more random gripes, but you get the idea - routeros definitely shows a certain lack of polish but can get the job done for low-end stuff at a very acceptably low-end price. All in all, despite the gripes it's worth your time to check out. Don't let the folks who sing their praises get your hopes up too much but hey, for pocket change invested? Pretty decent. There are some good surprises in there too, like putative support for 32 bit ASNs (haven't tested that myself) and scriptability that will allow you to send TSIG-signed dns update messages periodically for when you have customers to support that are on the far end of a non-sticky DHCP. -r
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to enable/encourage
this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
pgpX6O3mDI4Ie.pgp
Description: PGP signature
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is a dark traffic signal is a 4-way stop. I'm not so sure that's true. (The 2-3 orders of magnitude part). When I worked ambulance, we responded to a lot more collisions in 4-way stop intersections and malfunctioning (dark or flashing red) signal intersections than we did in intersections with conflicting greens. A whole lot ore, like none of the conflicting greens and many of the others. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think new Coke. Sorry, I have trouble understanding how you draw a parallel between a crossing greens accident and new coke. Yes, people assume a crossing greens situation is completely impossible. People assume a lot of very unlikely things are completely impossible. Many people think that winning the lottery is completely impossible for them. A fraction of those people choose not to play on that basis, rendering that belief basically true. Even with modern software-controlled signaling, crossing greens events are extremely uncommon. So much so that I have never actually encountered one. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Sure. But we have no numbers on either side. I will say that the relative complexity of configuring the software systems vs. wiring a relay based system to correctly protect a modern complex intersection would make the relay system inherently significantly less likely to have completely protected logic. In fact, it might even be electrically impossible to completely protect the logic in some modern intersection configurations because they don't make relays with that many poles. Conversely, the software configuration interface is pretty well abstracted to the level of essentially describing the intersection in terms of source/destination pairs and paths crossed by each pair. Short of a serious bug in the overall firmware or the configuration compiler (for lack of a better term), I'd say that such gross errors in the configuration of the conflict monitor are pretty unlikely. Indeed, the history of traffic light malfunctions with digital controllers would seem to bear this out. The safety record appears to be pretty good. So rare, in fact, that traffic light malfunctions do not appear in a list of traffic accident causes that totaled more than 99% of traffic accidents when I added up the percentages. I can only assume that since light malfunctions overall are not a statistically significant fraction of accidents, conflicting greens must represent an even smaller and more insignificant fraction. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. See above about whether people trust green lights to be safe. People trust cars to be safe. What is your point? Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 12:30 PM, valdis.kletni...@vt.edu wrote:
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to
enable/encourage this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
That would be John Mayes. The PIX was an outgrowth of Cisco's purchase of
a company called Network Address Translation (translation.com back in the
day). Frankly, the trend towards NAT and the need for some level of security
that was evolving in that day made most of those things inevitable.
Were there better approaches, perhaps. However, even with the PIX in place,
I think that Micr0$0ft did more to make http-based tunneling a widespread and
common phenomenon. It may have been pragmatic from their perspective, but,
it was also damaging to the internet and they were the ones that chose to be
pragmatic like that on a wide scale.
Owen
Re: Dynamic (changing) IPv6 prefix delegation
*** *** right. *** like * ** to ** *** what *** * ***
** **.
:)
--
Brielle
(sent from my phone)
On Nov 22, 2011, at 1:30 PM, valdis.kletni...@vt.edu wrote:
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to
enable/encourage this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
Re: OT: Traffic Light Control
On Tue, Nov 22, 2011 at 02:26:34PM -0500, Jay Ashworth wrote: Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, My understanding was that it was completely impossible. You could fail dark, but you *could not* fail crossing-green. Just to put one point to rest. I, personally, have witnessed traffic lights showing 'green both directions'. *TWICE*. One was in the mid-1960s, with what was undoubtedly relay-based control logic; the second was in the late 1990s, *probably* with solid-state 'management' controls , but I don't know for certain. (The 'relatively recent' unit's I've seen the insides of have solid-state logic driving final 'output' relays that provide power to the actual signal head.) In the first case, the pedestal-mounted control unit had been subjected to excessive impact forces, and some of the 'output' wires had shorted together.
RE: Any recommended router. They are reliable and have good support.
I could look though our customer list and show over 2,000 networks being ran by RouterOS from small networks running 20-50 meg all the way up to networks running 10GigE BGP feeds. We just turned up a location running 4 BGP GigE feeds in a single router. --- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of Learn RouterOS -Original Message- From: Joseph Sullivan [mailto:joseph.sulli...@alyrica.net] Sent: Tuesday, November 22, 2011 2:31 PM To: nanog@nanog.org Subject: Re: Any recommended router. They are reliable and have good support. We use a lot of Mikrotik in our network. They are fantastic little routers as long as you remember that they are not Cisco/Juniper/whatever. In other words, you pay a few hundred bucks, you get something worth at least that much. But don't put it head to head against a $10k router. Support is technically sound, but you have to email Latvia and then wait for the time difference to get a response. If you expect to pay $100 for a router and then get prompt, courteous, 24/7 tech support, you will be disappointed. :) We use their routers mostly for end user gateways doing QOS. They do a superb job of this. I wouldn't particularly want them as network edge devices or core routers; they will choke up if the PPS rate gets too high and you are doing any kind of packet mangling. There have been a lot of bugs in various versions of RouterOS, but the current (5.8?) OS seems pretty good. They added IPv6 support and fixed a ton of bugs. OSPF implementation was buggy before OS5, but seems to be relatively stable since we upgraded. BGP works fine but is perhaps less feature rich than Cisco/Zebra. Joseph Alyrica Networks Inc / www.alyrica.net - Original Message - From: Robert E. Seastrom r...@seastrom.com To: Leigh Porter leigh.por...@ukbroadband.com Cc: nanog list nanog@nanog.org Sent: Tuesday, November 22, 2011 11:52 AM Subject: Re: Any recommended router. They are reliable and have good support. Leigh Porter leigh.por...@ukbroadband.com writes: Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? I have dealt with Mikrotik support. They were easily comparable to [CJ]TAC. Which is to say guy was pleasant and courteous, I could tell through the language barrier that he wasn't really interested in addressing my problems or understanding them, and eventually I got exasperated and figured out a work-around. That said, it's easy to exceed expectations when you've spent something like $70 on a router that does five ports of gigabit ethernet. Several dot releases after that little ordeal, at least one of my laundry list of problems (ssh connections blew up if you are using application layer keepalives) seems to have gotten fixed, at least in 5.8, with nary a mention in the release notes so I assume it was a matter of syncing the codebase to whatever they run for an ssh server. Still no fix for the your CLI only partially implements Emacs key binds, please try libcli.a which is LGPL instead, which is annoying since this shortcoming is really up in your grill whenever you're logged into the router. Still can't traceroute to an IPv6 host by name, only by number. Dunno if they figured out what the G in GRE stands for yet and started allowing protocols other than IPv4 (and ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to test it out since I managed to get 6in4 tunneling working instead. There are more random gripes, but you get the idea - routeros definitely shows a certain lack of polish but can get the job done for low-end stuff at a very acceptably low-end price. All in all, despite the gripes it's worth your time to check out. Don't let the folks who sing their praises get your hopes up too much but hey, for pocket change invested? Pretty decent. There are some good surprises in there too, like putative support for 32 bit ASNs (haven't tested that myself) and scriptability that will allow you to send TSIG-signed dns update messages periodically for when you have customers to support that are on the far end of a non-sticky DHCP. -r
Net Brain?
Anyone using Net Brain? Just curious what you think Barry Jones - CISSP GSNA P please don't print this e-mail unless you really need to.
Re: First real-world SCADA attack in US
On 11/22/2011 5:59 AM, Brett Frankenberger wrote: The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. -- Brett Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. Matthew Kaufman
Re: First real-world SCADA attack in US
Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew
Re: First real-world SCADA attack in US
Steven Bellovin wrote: On Nov 21, 2011, at 4:30 PM, Mark Radabaugh wrote: Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. Somewhere there is a terrified 12 year old. Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. That's precisely the problem: it does appear to have been an easy attack. (My thoughts are at https://www.cs.columbia.edu/~smb/blog/2011-11/2011-11-18.html) --Steve Bellovin, https://www.cs.columbia.edu/~smb Umm hmm. And here's another one poking around: http://pastebin.com/Wx90LLum I'm not going to expose the details of the box. No damage was done to any of the machinery; I don't really like mindless vandalism. It's stupid and silly. On the other hand, so is connecting interfaces to your SCADA machinery to the Internet. I wouldn't even call this a hack, either, just to say. This required almost no skill and could be reproduced by a two year old with a basic knowledge of Simatic. --Michael
Re: First real-world SCADA attack in US
- Original Message - From: Matthew Kaufman matt...@matthew.at Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. If you mean an independent conflict monitor which, *in the event there is NO discernable fault*, *connects* the controller to the lamp outputs... so that in the event the monitor itself fails, gravity or springs will return those outputs to the flasher circuit, than I'll accept that latter assertion. 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: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: - Original Message - From: Matthew Kaufman matt...@matthew.at Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. If you mean an independent conflict monitor which, *in the event there is NO discernable fault*, *connects* the controller to the lamp outputs... so that in the event the monitor itself fails, gravity or springs will return those outputs to the flasher circuit, than I'll accept that latter assertion. That protects against a conflicting output from the controller at the same time the conflict monitor completely dies (assuming its death is in a manner that removes voltage from the relays). It doesn't protect against the case of conflicting output from the controller which the conflict monitor fails to detect. (Which is one of the cases you seemed to be concerned about before.) -- Brett
Re: First real-world SCADA attack in US
andrew.wallace wrote: Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. I'd bet we'll soon be hearing more from this loldhs pr0f character in .ro. --Michael
Re: First real-world SCADA attack in US
This might be of interest to those wishing to dive deeper into the subject. Telecommunications Handbook for Transportation Professionals: The Basics of Telecommunications by the Federal Highway Administration. http://ops.fhwa.dot.gov/publications/telecomm_handbook/ I'm still digging through it to see what they say about network security. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: First real-world SCADA attack in US
On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... pgpo3MwGWHfe8.pgp Description: PGP signature
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 5:23 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: in a manner that removes voltage from the relays). It doesn't protect against the case of conflicting output from the controller which the conflict monitor fails to detect. (Which is one of the cases you seemed to be concerned about before.) Reliable systems have triple redundancy. And indeed... hardwired safety is a lot better than relying on software. But it's not like transistors/capacitors don't fail either, so whether solid state or not, a measure of added protection is in order beyond a single monitor. There should be a conflict monitor test path that involves a third circuit intentionally creating a safe test conflict at pre-defined sub-millisecond intervals, by generating a conflict in a manner the monitor is supposed to detect but won't actually produce current through the light, and checking for absence of a test signal on green; if the test fails, the test circuit should intentionally blow a pair of fuses, breaking the test circuit's connections to the controller and conflict monitor. In addition the 'test circuit' should generate a pair of clock signals of its own, that is a side effect and only possible with correct test outcomes and will be verified by both the conflict monitor and the controller; if the correct clock indicating successful test outcomes is not detected by either the conflict monitor or by the controller, both systems should independently force a fail, using different methods. So you have 3 circuits, and any one circuit can detect the most severe potential failure of any pair of the other circuits. -- Brett -- -JH
Re: First real-world SCADA attack in US
- Original Message - From: Jimmy Hess mysi...@gmail.com So you have 3 circuits, and any one circuit can detect the most severe potential failure of any pair of the other circuits. Just so. Byzantine monitoring, just like a Byzantine clock. 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: First real-world SCADA attack in US
Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Steven Bellovin s...@cs.columbia.edu wrote: On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
Note to self. When my opc/modbus code goes to hell and wipes out an hvac unit; blame cyber terrorists, crappy vendors, and provide a random shady ip address. This was sad when it was possibly an unprotected network, with poor password procedures, horrible protection code in the logics, etc etc. Now it even got worse. Sigh. Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 11/22/2011 6:32 PM, Michael Painter wrote: andrew.wallace wrote: Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. I'd bet we'll soon be hearing more from this loldhs pr0f character in .ro. --Michael
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb Weiss expressed frustration over the conflicting reports. Somewhat related...New broom at DHS. From SANS NewsBites Vol.13, Num.93: Good News! Yesterday, Mark Weatherford took over as Deputy Undersecretary for Cyber Security at the U.S. Department of Homeland Security. For the first time in many years, the U.S. cybersecurity program will be run by a technologist rather than by a lawyer. There are good reasons to believe that this change will herald an era of greater balance in national cybersecurity leadership between NSA and DHS.
Re: First real-world SCADA attack in US
There is no evidence to support claims made in initial reports -- which were based on raw, unconfirmed data and subsequently leaked to the media. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html From what I'm seeing and hearing is the report by the fusion centre was private and facts were still being *fusioned* when somebody decided to leak to the media. What we had was a half baked report not ment for public consumption. What needs to be looked at is lockering out certain people who think its OK to leak reports from these state resources. Andrew
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/22/11 8:16 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. The perceived risk in this case is multiple high-speed traffic fatalities. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. I'm familiar with this. The modern Safetran brand of traffic light controllers are indeed microprocessor based and networked for time sync, although they can also use local GPS. Network is typically radio or twisted pair modem. McCain, BiTran, etc. are similar. The master controllers do run IP so the risk is there that they can be either deliberately or accidentally exposed to the Internet. Before this they typically had a dial-up modem and could be accessed by anyone war-dialing with a VT-100 emulator and some password guessing. Many are still this way. Within each intersection controller is a PC board with a diode matrix called a conflict monitor. It has inputs from all of the green and yellow phases including pedestrian walk signals, turn arrows, etc. It's the job of the traffic engineer installing the system to program the conflict monitor for that intersection. By default they're programmed for a simple North-South vs. East-West intersection of two-way streets with pedestrian controls. If anything different, the conflict monitor is reprogrammed in the field to match the intersection. In the event of a conflict, defined as green, yellow or walk signals that would cause conflicting traffic being allowed, the conflict monitor forces the intersection into red flashing in all directions and disconnects control from the microprocessor until manually reset on-site. If networked, it also sends a conflict alarm. If the conflict monitor is removed, the intersection goes to flash. Conflicting green is only possible if the conflict monitor is mis-programmed or the external connections to the signal heads are mis-wired. Even a short-circuit in the external wiring between two green phases would be detected unless the feed wires of the conflicting phases are cut to the signal box. In the real world, Stuff happens. Trucks cut corners and turn the traffic heads to point the wrong way. Controllers get replaced with a stock unit after a failure or accident knocking down the signal box without being properly set up for that intersection. But, an external cracker even with full access won't be able to cause a conflict. Massive traffic jams by messing with the timing, short or long cycles, etc. but not a conflict. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
