RE: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing
Pardon the ignorance I have to take this a step back. Your neighbor leaves their window open with a fresh bowl of fish near the window. A bunch of cats show up and start trying to get in, to no avail do they get in. At the first chance you discuss this with your neighbor, and warn them of this situation. The following day the neighbor does the same thing, window open, fresh bowl of fish, do you A: sit back and say Told you so. B: Swat the cats away and guard the window. C: kill all the cats in the area. D: hire the cats to find another open window. I know this sounds silly, but to simplify things, If you A: Sitting back and watching the whole mess your now an accessory (Yeah I watched em) B: Neighbor says Hey I wanted to take pictures of those cats and you shoed them away! C: Vigilante style kill all the cats. Closing a window just is too much. D: Hire cats? Perhaps another EDS commercial. If theres a genuine exploit that one has been made aware of, and there is no preventive action made than I think we all know the outcome. If theres a sudden exploit that runs ramped that you haven't been aware of than lots of time spent researching it. Locking up all the bad guys will not solve the short comings of security in applications. But just my 2¢s - Joe Blanchard -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Saturday, April 18, 2009 12:56 AM To: andrew.wallace Cc: n3td3v; nanog@nanog.org Subject: Re: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing So if Al-Qaeda blow up a shopping centre and the guy who masterminded it turns out to be 17 he gets a job in MI5? what is more fun than a net vigilante? a ranting and raving hyperbolic net vigilante.
Re: IXP
From: Paul Vixie vi...@isc.org Date: Sat, 18 Apr 2009 00:08:04 + ... i should answer something said earlier: yes there's only 14 bits of tag and yes 2**14 is 4096. in the sparsest and most wasteful allocation scheme, tags would be assigned 7:7 so there'd be a max of 64 peers. i meant of course 12 bits, that 2**12 is 4096, and 6:6. apologies for slop.
Lease4web abuse contact
Does anyone have an abuse contact for lease4web that they can contact me off list about, the normal channels don't seem to be working here in regards to some pesky hackers. Regards, Nick Rose
Re: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing
I have to take this a step back. Your neighbor leaves their window open with a fresh bowl of fish near the window. what i do is laugh at the fool and hit delete
Re: IXP
stephen, any idea why this hasn't hit the nanog mailing list yet? it's been hours, and things that others have sent on this thread has appeared. is it stuck in a mail queue? --paul re: To: Deepak Jain dee...@ai.net cc: Matthew Moyle-Croft m...@internode.com.au, Arnold Nipper arn...@nipper.de, Paul Vixie vi...@isc.org, na...@merit.edu na...@merit.edu Subject: Re: IXP Date: Sat, 18 Apr 2009 05:30:41 + From: Stephen Stuart stu...@tech.org Not sure how switches handle HOL blocking with QinQ traffic across trunks, but hey... what's the fun of running an IXP without testing some limits? Indeed. Those with longer memories will remember that I used to regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI head-of-line blocking that all Gigaswitch-based IXPs experienced when some critical mass of OC3 backbone circuits was reached and the 100 MB/s fabric rolled over and died, offered here (again) as a cautionary tale for those who want to test those particular limits (again). At PAIX, when we upgraded to the Gigaswitch/FDDI (from a DELNI; we loved the DELNI), I actually used a feature of the switch that you could black out certain sections of the crossbar to prevent packets arriving on one port from exiting certain others at the request of some networks to align L2 connectivity with their peering agreements. It was fortunate that the scaling meltdown occurred when it did, otherwise I would have spent more software development resources trying to turn that capability into something that was operationally sustainable for networks to configure the visibility of their port to only those networks with which they had peering agreements. That software would probably have been thrown away with the Gigaswitches had it actually been developed, and rewritten to use something horrendous like MAC-based filtering, and if I recall correctly the options didn't look feasible at the time - and who wants to have to talk to a portal when doing a 2am emergency replacement of a linecard to change registered MAC addresses, anyway?. The port-based stuff had a chance of being operationally feasible. The notion of a partial pseudo-wire mesh, with a self-service portal to request/accept connections like the MAEs had for their ATM-based fabrics, follows pretty well from that and everything that's been learned by anyone about advancing the state of the art, and extends well to allow an IXP to have a distributed fabric benefit from scalable L2.5/L3 traffic management features while looking as much like wires to the networks using the IXP. If the gear currently deployed in IXP interconnection fabrics actually supports the necessary features, maybe someone will be brave enough to commit the software development resources necessary to try to make it an operational reality. If it requires capital investment, though, I suspect it'll be a while. The real lesson from the last fifteen or so years, though, is that bear skins and stone knives clearly have a long operational lifetime. Stephen
RE: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing
lol, in a virtual world its always nice to have the delete key (: -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Saturday, April 18, 2009 3:10 AM To: Jo¢ Cc: 'andrew.wallace'; 'n3td3v'; nanog@nanog.org Subject: Re: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing I have to take this a step back. Your neighbor leaves their window open with a fresh bowl of fish near the window. what i do is laugh at the fool and hit delete
Re: IXP
- kris foster kris.fos...@gmail.com wrote: painfully, with multiple circuits into the IX :) I'm not advocating Paul's suggestion at all here Kris Totally agree with you Kris. For the IX scenario (or at least looking in a Public way) it seems Another Terrible Mistake to me. IMHO, when you are in a Public IX, you usually want to reach everyone's network without hassling around. Then it is your problem, and yours peer problem if we peer or not. When you overload a certain port at a Public IX, you rather upgrade that Port, or, Move particular bit pushers and movers for a Private Peering port (if it really makes technical and economical sense). I don't see how this idea that came out there could benefit the operational daily works (For IX, For IX Customers) , also, it would require work from the (usually) Neutral IX, when users need to connect ear other, which, will lead in more money to pay. (hey IX OPS.. we are company X and Z, and we signed a nice peering agreement.. can you please virtual patch us ?) Where is the neutrality here ? Time ? What if my equipment brokes at 3 AM and IX Ops need to change configs ? Ok, ones could say... it is automated... BUT.. what is the really security behind automation ? The portal is on the Wild Web, right ? This happens today on datacenters, with real cross connects, usually thru MMR's (Meet me Rooms).I don't want to have a Virtual Meet me Room, on Internet exchanges where i peer. This is my view. I might be wrong, but i don't care, as i am square as a rock. :-) I don't understand how can this new concept (or really old, considering ancient ATM peering and stuff), can be better, more secure, and cheaper for all. cheers, --nvieira
Re: IXP
On Sat, Apr 18, 2009 at 05:30:41AM +, Stephen Stuart wrote: Not sure how switches handle HOL blocking with QinQ traffic across trunks, but hey... what's the fun of running an IXP without testing some limits? Indeed. Those with longer memories will remember that I used to regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI head-of-line blocking that all Gigaswitch-based IXPs experienced when some critical mass of OC3 backbone circuits was reached and the 100 MB/s fabric rolled over and died, offered here (again) as a cautionary tale for those who want to test those particular limits (again). Ohhh... Scary Stories! :) The real lesson from the last fifteen or so years, though, is that bear skins and stone knives clearly have a long operational lifetime. well... while there is a certain childlike obession with the byzantine, rube-goldburg, lots of bells, knobs, whistles type machines... for solid, predictable performance, simple clean machines work best. Stephen --bill
Re: IXP
On 18/04/2009 01:08, Paul Vixie wrote: i've spent more than several late nights and long weekends dealing with the problems of shared multiaccess IXP networks. broadcast storms, poisoned ARP, pointing default, unintended third party BGP, unintended spanning tree, semitranslucent loops, unauthorized IXP LAN extension... all to watch the largest flows move off to PNI as soon as somebody's port was getting full. Paul- to be fair, things might have moved on a little since the earlier years of internet exchanges. These days, we have switches which do multicast and broadcast storm control, unicast flood control, mac address counting, l2 and l3 acls, dynamic arp inspection, and they can all be configured to ignore bpdus in a variety of imaginative ways. We have arp sponges and broadcast monitors. We have edge routers which can do multiple flavours of urpf, and for those hardcore types who don't like md5 or gtsm, there's always ipsec for bgp sessions. I have to be honest: i just don't care if people use L2 connectivity to get to an exchange from a router somewhere else on their LAN. They have one mac address to play around with, and if they start leaking mac addresses towards the exchange fabric, all they're going to do is hose their own connectivity. If they are silly enough to enable stp at their edge, then that will trash their connectivity, as a carrier up event will trigger STP packets from their switch before their router notices, and mac learning will prevent their router from gaining access to the exchange. If they decide to loop their L2 traffic, do I care? They'll just be chopped off automatically, and I'll get an email. And if people behave really cretinously, I'll just bang in more L2 or L3 filters to stop them from tickling my monitoring systems, but most likely at that stage, they will have been extensively depeered due to technical ineptitude. Stupid behaviour is self-limiting and is really just an annoyance these days rather than a problem. As you've noted, there is a natural progression for services providers here from shared access to pni, which advances according to the business and financial requirements of the parties involved. If exchange users decide to move from shared access peering to PNI, good for them - it means their business is doing well. But this doesn't mean that IXPs don't offer an important level of service to their constituents. Because of them, the isp industry has convenient access to dense interconnection at a pretty decent price. Q in Q is not how i'd build this... cisco and juniper both have hardware tunnelling capabilities that support this stuff... it just means as the IXP fabric grows it has to become router-based. Hey, I have an idea: you could take this plan and build a tunnel-based or even a native IP access IXP platform like this, extend it to multiple locations and then buy transit from a bunch of companies which would give you a native L3 based IXP with either client prefixes only or else an option for full DFZ connectivity over the exchange fabric. You could even build a global IXP on this basis! It's a brilliant idea, and I just can't imagine why no-one thought of it before. Nick
Re: Michael Mooney releases another worm: Law Enforcement /Intelligence Agency's do nothing
lol, in a virtual world its always nice to have the delete key (: Best invention since packet switching which many said it will never work. Regards Jorge
Re: IXP
Date: Sat, 18 Apr 2009 10:09:00 + From: bmann...@vacation.karoshi.com ... well... while there is a certain childlike obession with the byzantine, rube-goldburg, lots of bells, knobs, whistles type machines... for solid, predictable performance, simple clean machines work best. like you i long for the days when a DELNI could do this job. nobody makes hubs anymore though. but the above text juxtaposes poorly against the below text: Date: Sat, 18 Apr 2009 16:35:51 +0100 From: Nick Hilliard n...@foobar.org ... These days, we have switches which do multicast and broadcast storm control, unicast flood control, mac address counting, l2 and l3 acls, dynamic arp inspection, and they can all be configured to ignore bpdus in a variety of imaginative ways. We have arp sponges and broadcast monitors. ... in terms of solid and predictable i would take per-peering VLANs with IP addresses assigned by the peers themselves, over switches that do unicast flood control or which are configured to ignore bpdu's in imaginative ways. but either way it's not a DELNI any more. what i see is inevitable complexity and various different ways of layering that complexity in. the choice of per-peering VLANs represents a minimal response to the problems of shared IXP fabrics, with maximal impedance matching to the PNI's that inevitably follow successful shared-port peerings.
Re: IXP
Date: Sat, 18 Apr 2009 16:35:51 +0100 From: Nick Hilliard n...@foobar.org ... i just don't care if people use L2 connectivity to get to an exchange from a router somewhere else on their LAN. They have one mac address to play around with, and if they start leaking mac addresses towards the exchange fabric, all they're going to do is hose their own connectivity. yeah we did that at PAIX. if today's extremenetworks device has an option to learn one MAC address per port and no more, it's because we had a terrible time getting people to register their new MAC address when they'd change out interface cards or routers. hilarious levels of fingerpointing and downtime later, our switch vendor added a knob for us. but we still saw typo's in IP address configurations whereby someone could answer ARPs for somebody else's IP. when i left PAIX (the day MFN entered bankruptcy) we were negotiating for more switch knobs to prevent accidental and/or malicious ARP poisoning. (and note, this was on top of a no-L2-devices rule which included draconian auditing rights for L2/L3 capable hardware.) As you've noted, there is a natural progression for services providers here from shared access to pni, which advances according to the business and financial requirements of the parties involved. If exchange users decide to move from shared access peering to PNI, good for them - it means their business is doing well. But this doesn't mean that IXPs don't offer an important level of service to their constituents. Because of them, the isp industry has convenient access to dense interconnection at a pretty decent price. yes, that's the progression of success. and my way of designing for success is to start people off with VNI's (two-port VLANs containing one peering) so that when they move from shared-access to dedicated they're just moving from a virtual wire to a physical wire without losing any of the side-benefits they may have got from a shared-access peering fabric. Q in Q is not how i'd build this... cisco and juniper both have hardware tunnelling capabilities that support this stuff... it just means as the IXP fabric grows it has to become router-based. Hey, I have an idea: you could take this plan and build a tunnel-based or even a native IP access IXP platform like this, extend it to multiple locations and then buy transit from a bunch of companies which would give you a native L3 based IXP with either client prefixes only or else an option for full DFZ connectivity over the exchange fabric. You could even build a global IXP on this basis! It's a brilliant idea, and I just can't imagine why no-one thought of it before. :-). i've been known to extend IXP fabrics to cover a metro, but never beyond.
Re: IXP
On Sat, Apr 18, 2009 at 04:01:41PM +, Paul Vixie wrote: Date: Sat, 18 Apr 2009 10:09:00 + From: bmann...@vacation.karoshi.com ... well... while there is a certain childlike obession with the byzantine, rube-goldburg, lots of bells, knobs, whistles type machines... for solid, predictable performance, simple clean machines work best. like you i long for the days when a DELNI could do this job. nobody makes hubs anymore though. but the above text juxtaposes poorly against the below text: i never said i longed for DELNI's (although there is a naive beauty in such things) i make the claim that simple, clean design and execution is best. even the security goofs will agree. but either way it's not a DELNI any more. what i see is inevitable complexity and various different ways of layering that complexity in. the choice of per-peering VLANs represents a minimal response to the problems of shared IXP fabrics, with maximal impedance matching to the PNI's that inevitably follow successful shared-port peerings. complexity invites failure - failure in unusual and unexpected ways. small simple systems are more nimble, faster and more resilient. complex is usually big, slow, fraught w/ little used code paths, a veritable nesting ground for virus, worm, half-baked truths, and poorly tested assumptions. one very good reason folks move to PNI's is that they are simpler to do. More cost-effective -AT THAT performance point-. I worry (to the extent that I worry about such things at all these days) that the code that drives the Internet these days is bloated, slow, and generally trying to become the swiss-army-knife application of critial infrastructure joy. witness BGP. more knobs/whistles than you can shake a stick at. the distinct lack of restraint by code developers in their desire to add every possible feature is argueably the primary reason the Internet is so riddled with security vulnerabilities. I'll get off my soap-box now and let you resume your observations that complexity as a goal in and of itself is the olny path forward. What a dismal world-view. --bill
Re: IXP
On Sat, 18 Apr 2009 16:58:24 + bmann...@vacation.karoshi.com wrote: i make the claim that simple, clean design and execution is best. even the security goofs will agree. Even? *Especially* -- or they're not competent at doing security. But I hadn't even thought about DELNIs in years. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: IXP
On 17/04/2009 15:11, Sharlon R. Carty wrote: I like would to know what are best practices for an internet exchange. I have some concerns about the following; Can the IXP members use RFC 1918 ip addresses for their peering? Can the IXP members use private autonomous numbers for their peering? Maybe the answer is obviuos, but I like to know from any IXP admins what their setup/experiences have been. If it's your exchange, you can do anything you want. I one saw a network which used 127.0.0.0/8 for connectivity. But I'd strongly suggest insisting from day 1: - public IP addresses for ipv4 and ipv6 - requirement for all members to use BGP, their own ASN and their own address space - no customer IGPs - dropping customer bpdus on sight - ruthless and utterly fascist enforcement of one mac address per port, using either L2 ACLs or else mac address counting, with no exceptions for any reason, ever. This is probably the single more important stability / security enforcement mechanism for any IXP. You should also take a look at the technical requirements on some of the larger european IXP web sites (linx / ams-ix / decix / etc), to see what they allow and don't allow. It goes without saying that you're not going to be able to do this on your average low-end switch. Nick
Re: IXP
Paul Vixie wrote: in terms of solid and predictable i would take per-peering VLANs with IP addresses assigned by the peers themselves, over switches that do unicast flood control or which are configured to ignore bpdu's in imaginative ways. Simplicity only applies when it doesn't hinder security (the baseline complexity). PE/BRAS systems suffer from a subset of IXP issues with a few of their own. It amazes me how much security has been pushed from the PE out into switches and dslams. Enough so, that I've found many vendors that break IPv6 because of their security features. 1Q tagging is about the simplest model I have seen for providing the necessary isolation, mimicking PNI. For PE, it has allowed complete L3 ignorance in the L2 devices while enforcing security policies at the aggregation points. For an IXP it provides the necessary isolation and security without having an expectation of the type of L3 traffic crossing through the IXP. It's true that 1Q tagging requires a configuration component, but I'd hesitate to call it complex. 10,000 line router configs may be long, but often in repetition due to configuration limitations rather than complex. HE's IPv6 tunnel servers are moderately more complex and have handled provisioning well in my experience. Multicast was brought up as an issue, but it's not less efficient than if PNI had been used, and a structure could be designed to meet the needs of multicast when needed. Jack
Re: downloading speed
Dear Members, Thanks for your help and valuable information. Finally the issue resolved after card reset. Case has been book with Cisco. I will update you with the outcome of Cisco once they update us... Thanks Chandrashakher pawar On Sat, Apr 18, 2009 at 1:08 AM, b nickell nickell...@gmail.com wrote: Duplex Mismatch looks to be the problem. On Fri, Apr 17, 2009 at 3:23 PM, chandrashakher pawar learn.chan...@gmail.com wrote: Dear Group member, We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. our router is C12KPRP-K4P-M Please advise what could be the cause? -- Regards Chandrashakher Pawar IPNOC Customer Services Operations Tata communication AS6453 mobil + 91 9225633948 + 91 9324509268 learn.chan...@gmail.com -- -B
Re: IXP
I'll get off my soap-box now and let you resume your observations that complexity as a goal in and of itself is the olny path forward. What a dismal world-view. No-one is arguing that complexity is a goal. Opportunities to introduce gratuitous complexity abound, and defending against them while recognizing that the opportunity that represents genuine progress (trading outhouses for indoor plumbing, for example) is quite a challenge. I'm all for using the cleanest, simplest, and most reliable means to meet requirements. Not all IXPs have the same requirements driving their business, though - an IXP that operates a distributed metro-area fabric has additional concerns for reliability and cost-efficient use of resources than an IXP that operates a single switch. If requirements were such that I needed to buy and *use* a partial mesh topology for a distributed IXP fabric in the most reliable fashion possible, I'd much rather go the route described earlier than try to cobble something together with PVST/MST L2 technologies, but that's just me. You can assert that the status quo gives you solid predictable performance, but the reality is that you occasionally get sucked into a vortex of operational issues arising from L2's failure modes. To continue with my bad plumbing analogy, open sewers were a reliable means of moving waste material, easy to see when they were failing, but occasionally produced outbreaks of disease. Are open sewers still in use in the world today? You bet. The underlying hardware layer that IXPs use is capable of more than IXPs use. Whether to turn on those features is driven by requirements, from customers and from the economics of the business. I would argue, though, that at today's level of robustness and penetration of the technologies that we've been discussing, the customer requirement to peer on a shared VLAN is much more about complacency than avoiding risk (as you seem to be arguing). When we were turning PAIX from a private interconnect location into a public IXP, we questioned every assumption about what role IXPs played in order to ensure that we weren't making decisions simply to preserve the status quo. One of the things we questioned was whether to offer a peering fabric at all, or simply rely on PNIs. Obviously we opted to have a peering fabric, and I don't regret the decision despite the many long nights dealing with migration from FDDI to Ethernet (and the fun of translational bridge MTU-related issues during the migration), and the failure modes of Ethernet L2 - so your assertion that Ethernet L2 provides solid predictable performance needs to be modified with mostly. I'll counter with an assertion that some L2.5/L3 networks are built and operated to more 9s than some IXP L2 networks that span multiple chassis. Whether that additional reliability makes business sense to offer, though, is a different question. If lack of complexity was a *requirement* that trumped all others, there would still be a DELNI at PAIX.
Re: IXP
Stephen, that's a straw-man argument. Nobody's arguing against VLANs. Paul's argument was that VLANs rendered shared subnets obsolete, and everybody else has been rebutting that. Not saying that VLANs shouldn't be used. Sent via BlackBerry by ATT -Original Message- From: Stephen Stuart stu...@tech.org Date: Sat, 18 Apr 2009 18:05:03 To: bmann...@vacation.karoshi.com Cc: na...@merit.edu na...@merit.eduna...@merit.edu Subject: Re: IXP I'll get off my soap-box now and let you resume your observations that complexity as a goal in and of itself is the olny path forward. What a dismal world-view. No-one is arguing that complexity is a goal. Opportunities to introduce gratuitous complexity abound, and defending against them while recognizing that the opportunity that represents genuine progress (trading outhouses for indoor plumbing, for example) is quite a challenge. I'm all for using the cleanest, simplest, and most reliable means to meet requirements. Not all IXPs have the same requirements driving their business, though - an IXP that operates a distributed metro-area fabric has additional concerns for reliability and cost-efficient use of resources than an IXP that operates a single switch. If requirements were such that I needed to buy and *use* a partial mesh topology for a distributed IXP fabric in the most reliable fashion possible, I'd much rather go the route described earlier than try to cobble something together with PVST/MST L2 technologies, but that's just me. You can assert that the status quo gives you solid predictable performance, but the reality is that you occasionally get sucked into a vortex of operational issues arising from L2's failure modes. To continue with my bad plumbing analogy, open sewers were a reliable means of moving waste material, easy to see when they were failing, but occasionally produced outbreaks of disease. Are open sewers still in use in the world today? You bet. The underlying hardware layer that IXPs use is capable of more than IXPs use. Whether to turn on those features is driven by requirements, from customers and from the economics of the business. I would argue, though, that at today's level of robustness and penetration of the technologies that we've been discussing, the customer requirement to peer on a shared VLAN is much more about complacency than avoiding risk (as you seem to be arguing). When we were turning PAIX from a private interconnect location into a public IXP, we questioned every assumption about what role IXPs played in order to ensure that we weren't making decisions simply to preserve the status quo. One of the things we questioned was whether to offer a peering fabric at all, or simply rely on PNIs. Obviously we opted to have a peering fabric, and I don't regret the decision despite the many long nights dealing with migration from FDDI to Ethernet (and the fun of translational bridge MTU-related issues during the migration), and the failure modes of Ethernet L2 - so your assertion that Ethernet L2 provides solid predictable performance needs to be modified with mostly. I'll counter with an assertion that some L2.5/L3 networks are built and operated to more 9s than some IXP L2 networks that span multiple chassis. Whether that additional reliability makes business sense to offer, though, is a different question. If lack of complexity was a *requirement* that trumped all others, there would still be a DELNI at PAIX.
Re: IXP
I have been looking at ams-ix and linx, even some african internet exchanges as examples. But seeing how large they are(ams-x linx) and we are in the startup phase, I would rather have some tips/examples from anyone who has been doing IXP for quite awhile. So far all the responses have been very helpful. On Apr 18, 2009, at 1:28 PM, Nick Hilliard wrote: On 17/04/2009 15:11, Sharlon R. Carty wrote: I like would to know what are best practices for an internet exchange. I have some concerns about the following; Can the IXP members use RFC 1918 ip addresses for their peering? Can the IXP members use private autonomous numbers for their peering? Maybe the answer is obviuos, but I like to know from any IXP admins what their setup/experiences have been. If it's your exchange, you can do anything you want. I one saw a network which used 127.0.0.0/8 for connectivity. But I'd strongly suggest insisting from day 1: - public IP addresses for ipv4 and ipv6 - requirement for all members to use BGP, their own ASN and their own address space - no customer IGPs - dropping customer bpdus on sight - ruthless and utterly fascist enforcement of one mac address per port, using either L2 ACLs or else mac address counting, with no exceptions for any reason, ever. This is probably the single more important stability / security enforcement mechanism for any IXP. You should also take a look at the technical requirements on some of the larger european IXP web sites (linx / ams-ix / decix / etc), to see what they allow and don't allow. It goes without saying that you're not going to be able to do this on your average low-end switch. Nick
Re: IXP
On 18.04.2009 21:51 Sharlon R. Carty wrote I have been looking at ams-ix and linx, even some african internet exchanges as examples. But seeing how large they are(ams-x linx) and we are in the startup phase, I would rather have some tips/examples from anyone who has been doing IXP for quite awhile. So far all the responses have been very helpful. Do what Nick suggested and you will run a real safe IXP. Nick knows how to do that. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: IXP
Date: Sat, 18 Apr 2009 13:17:11 -0400 From: Steven M. Bellovin s...@cs.columbia.edu On Sat, 18 Apr 2009 16:58:24 + bmann...@vacation.karoshi.com wrote: i make the claim that simple, clean design and execution is best. even the security goofs will agree. Even? *Especially* -- or they're not competent at doing security. wouldn't a security person also know about http://en.wikipedia.org/wiki/ARP_spoofing and know that many colo facilities now use one customer per vlan due to this concern? (i remember florian weimer being surprised that we didn't have such a policy on the ISC guest network.) if we maximize for simplicity we get a DELNI. oops that's not fast enough we need a switch not a hub and it has to go 10Gbit/sec/port. looks like we traded away some simplicity in order to reach our goals.
Re: IXP
On Sat, Apr 18, 2009 at 09:12:24PM +, Paul Vixie wrote: Date: Sat, 18 Apr 2009 13:17:11 -0400 From: Steven M. Bellovin s...@cs.columbia.edu On Sat, 18 Apr 2009 16:58:24 + bmann...@vacation.karoshi.com wrote: i make the claim that simple, clean design and execution is best. even the security goofs will agree. Even? *Especially* -- or they're not competent at doing security. wouldn't a security person also know about http://en.wikipedia.org/wiki/ARP_spoofing and know that many colo facilities now use one customer per vlan due to this concern? (i remember florian weimer being surprised that we didn't have such a policy on the ISC guest network.) if we maximize for simplicity we get a DELNI. oops that's not fast enough we need a switch not a hub and it has to go 10Gbit/sec/port. looks like we traded away some simplicity in order to reach our goals. er... 10G is old hat... try 100G. i'm not arguing for a return to smoke signals. i'm arguing that simplicity is often time gratuitously abandoned in favor of the near-term, quick buck. if i may paraphrase Albert, Things should be as simple as possible, but no simpler and ARP... well there's a dirt simple hack that the ethernet-based folks have never been able to shake. :) --bill
Re: IXP
Paul Vixie wrote: if we maximize for simplicity we get a DELNI. oops that's not fast enough we need a switch not a hub and it has to go 10Gbit/sec/port. looks like we traded away some simplicity in order to reach our goals. Agreed. Security + Efficiency = base complexity 1Q has great benefits in security while maintaining a reasonable base complexity compared to 1 mac per port/MAC acl + broadcast storm control + insert common L2/3 security/performance tweaks commonly used in a flat multi-point topology. Things grow more complex as you reach up into MPLS. I'll show my ignorance and ask if it's possible to handle multicast on a separate shared tag and maintain security and simplicity while handling unicast on p2p tags? Standard methods of multicast on the Internet are foreign to me, and tend to act differently than multicast feeds standardly used for video over IP in local segments (from what little I have read). Primarily, I believe there was a reliance of unicast routing by multicast, which separate L2 paths might break. Jack
Re: IXP
Stephen, that's a straw-man argument. Nobody's arguing against VLANs. Paul's argument was that VLANs rendered shared subnets obsolete, and everybody else has been rebutting that. Not saying that VLANs shouldn't be used. I believe shared VLANs for IXP interconnect are obsolete. Whether they get retired in favor of modern technology is another question, a business question. About a year and a half ago, I built something much like the alternative being discussed as a community service project; pseudo-wire services for VNIs (participants can encrypt or not depending on their need), and a shared L3 cloud with private ASN numbering to provide inter-participant IP connectivity and some shared transit. The fabric survives fiber cuts without any disruption in connectivity (I didn't get to spec the fiber paths, so there are some places where the ring collapses into a single fiber bundle); everyone's HIPAA and FERPA concerns were met at the design phase; user-visible problems have been few, and problem diagnosis has been simple. There aren't a lot of participants, so I didn't do much in the way of self-service automation for provisioning, but I can see where it would be fairly straightforward and nicely scalable. If I were back in the IXP business, building a distributed metro-area fabric, that's how I'd do it, and I'd invest in automated, self-service provisioning. There would be no shared VLAN. I predict that the network would be more reliable, and could be operated more cost-efficiently as a result.
Re: IXP
- public IP addresses for ipv4 and ipv6 - requirement for all members to use BGP, their own ASN and their own address space just to not confuse, that is behind the peering port. the peering port uses the exchange's ipv4/6 space - no customer IGPs - dropping customer bpdus on sight - ruthless and utterly fascist enforcement of one mac address per port, using either L2 ACLs or else mac address counting, with no exceptions for any reason, ever. This is probably the single more important stability / security enforcement mechanism for any IXP. You should also take a look at the technical requirements on some of the larger european IXP web sites (linx / ams-ix / decix / etc), to see what they allow and don't allow. sharlon, reread nick's advice a few times, maybe pin it to your wall. It goes without saying that you're not going to be able to do this on your average low-end switch. just curious. has anyone tried arista for smallish exchanges, before jumping off the cliff into debugging extreme, foundry, ... randy
Re: IXP
Thanks for talking about your PNIs. Let's see: Permit Next Increase Private Network Interface Private Network Interconnection Primary Network Interface and it goes on and on . . .
Re: IXP
On 19.04.2009 01:08 Randy Bush wrote just curious. has anyone tried arista for smallish exchanges, before jumping off the cliff into debugging extreme, foundry, ... last time I look at them their products lacked port security or anything similiar. Iirc it's on the roadmap for thier next generation of switches. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: IXP
On Apr 19, 2009, at 5:12 AM, Paul Vixie wrote: many colo facilities now use one customer per vlan due to this concern? Haven't most major vendors for years offered features in their switches which mitigate ARP-spoofing, provide per-port layer-2 isolation on a sub-VLAN basis, as well as implementing layer-3 anti- spoofing on a per-switchport basis (i.e., BCP38 on a per-switchport basis)? --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott
Re: IXP
Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening). When he discovered traffic loads coming from non-peers he'd drop in an ACL that blocked everything except ICMP - then tell the NOC to route the call to his desk with the third party finally gave up troubleshooting and called in... fun memories of the NAPs... jy On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: On 18/04/2009 01:08, Paul Vixie wrote: i've spent more than several late nights and long weekends dealing with the problems of shared multiaccess IXP networks. broadcast storms, poisoned ARP, pointing default, unintended third party BGP, unintended spanning tree, semitranslucent loops, unauthorized IXP LAN extension... all to watch the largest flows move off to PNI as soon as somebody's port was getting full.
Re: IXP
Remember when you didn't want to put in ACLs because you'd blow out the cpu on the router/card? Ah... That made networking fun! Deepak - Original Message - From: Jeff Young yo...@jsyoung.net To: Nick Hilliard n...@foobar.org Cc: Paul Vixie vi...@isc.org; na...@merit.edu na...@merit.edu Sent: Sat Apr 18 20:45:48 2009 Subject: Re: IXP Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening). When he discovered traffic loads coming from non-peers he'd drop in an ACL that blocked everything except ICMP - then tell the NOC to route the call to his desk with the third party finally gave up troubleshooting and called in... fun memories of the NAPs... jy On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote: On 18/04/2009 01:08, Paul Vixie wrote: i've spent more than several late nights and long weekends dealing with the problems of shared multiaccess IXP networks. broadcast storms, poisoned ARP, pointing default, unintended third party BGP, unintended spanning tree, semitranslucent loops, unauthorized IXP LAN extension... all to watch the largest flows move off to PNI as soon as somebody's port was getting full.
