Re: We hit half-million: The Cidr Report
Well, I was just a suit drone into one of their 100 little IT firm around the world. The nearest I got to an actual AA associate was during a 1 month project in Chicago (: Wasted my time really... They billed 3 months to their clients, for a project that took 1 month, and I was asked to fill the cubicle for 2 month doing nothing. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 18:43, Owen DeLong wrote: Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. Owen On May 1, 2014, at 12:56 PM, Alain Hebert aheb...@pubnix.net wrote: Hey, I worked for them (AA) in the early 90's =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 14:07, John Souter wrote: On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John
Re: We hit half-million: The Cidr Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/04/14 17:30, valdis.kletni...@vt.edu wrote: ... Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) If more auditors (of whatever type) were put in the street when they annoy their customer or act irrationally, the world might become a better place. John - -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ Working for the Internet sip:j...@linx.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlNiDWIACgkQbwHoykR44Oc6QQCfZd2+62OqHEM9Ua04IWAUmXMO c1sAn2A2vLYDknI0hqbti9lDZXUoi1v/ =2Bwf -END PGP SIGNATURE-
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
Well, Right now, 1/2 my day$ are spend doing PCI auditing, technical side, not as a QSA. There is not shortage of horror stories about my customers previous QSA... Best one to date... Firewalling the FC SANs from the pool of VMWares servers. Bill Telnet... I hope that QSA didn't let you keep that telnet facing any public interface without any protection. PS: Same deal with SSH ... encryption != protection since keylogging is way easier than sniffing packets. But at least you can limit SSH authentication to public keys. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 04/30/14 20:58, David Hubbard wrote: We just dealt with a vmware audit too; it was a joke. In any case, the thing I found curious with their auditor as well as a PCI QSA (fancy auditor), is that neither entity seemed to know IPv6 exists. The whole time I'm thinking okay, now why aren't you investigating these same attack vectors in IPv6? Just another reason PCI is not necessarily about security David -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ulf Zimmermann Sent: Wednesday, April 30, 2014 8:36 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report) The auditors VMware sent to us were just as bad. To ensure we weren't running rogue ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. Oh look, this MAC isn't listed as one of your virtual machines. It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC On Wed, Apr 30, 2014 at 2:31 PM, William Herrin b...@herrin.us wrote: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
On Thu, May 1, 2014 at 6:29 AM, Alain Hebert aheb...@pubnix.net wrote: Bill Telnet... I hope that QSA didn't let you keep that telnet facing any public interface without any protection. Hi Alain, The point I made, successfully, was that it was outside the firewall hence out of scope for the audit. What I do in a different security domain from the one which handles the credit card transactions is none of their business. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
Bill - anything that puts another routable network alongside of the card processing info is in scope. The real; issue is that the PCI-SSC decided to formally create a policy to hold the auditors harmless in their actions and that is about to change. Todd On 5/1/2014 8:52 AM, William Herrin wrote: On Thu, May 1, 2014 at 6:29 AM, Alain Hebert aheb...@pubnix.net wrote: Bill Telnet... I hope that QSA didn't let you keep that telnet facing any public interface without any protection. Hi Alain, The point I made, successfully, was that it was outside the firewall hence out of scope for the audit. What I do in a different security domain from the one which handles the credit card transactions is none of their business. Regards, Bill Herrin -- - Personal Email - Disclaimers Apply
Re: We hit half-million: The Cidr Report
On May 1, 2014, at 2:01 AM, John Souter j...@linx.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/04/14 17:30, valdis.kletni...@vt.edu wrote: ... Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) If more auditors (of whatever type) were put in the street when they annoy their customer or act irrationally, the world might become a better place. The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Owen
Re: We hit half-million: The Cidr Report
On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ Working for the Internet sip:j...@linx.net
Re: We hit half-million: The Cidr Report
On May 1, 2014, at 11:07 AM, John Souter j...@linx.net wrote: On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. I’m not saying that auditors shouldn’t be accountable or that people shouldn’t be able to do something about auditors that are being irrational/stupid. Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism” since NAT is a minor hindrance to security at best. I realize you’re not asking auditors to roll over, but finding a balance point is tricky. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. Many things failed in that situation. MOST of them should have been caught and stopped by financial auditing. Yes, it was financial auditing, but I don’t really see the difference. When you turn “pleasing the customer” into a potential conflict with “accurate audit results”, you create a recipe for trouble. As much as I want auditors accountable for unprofessional/illogical conduct (which does not yield “accurate results” anyway), I consider it critical to avoid putting auditors in the “a happy customer is a good customer with a happy audit” mentality because that leads to very bad places. The right place is somewhere between these extremes, but defining that location is quite difficult. Owen
Re: We hit half-million: The Cidr Report
Hey, I worked for them (AA) in the early 90's =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 14:07, John Souter wrote: On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John
Re: We hit half-million: The Cidr Report
On 4/29/2014 10:54 PM, Jeff Kell wrote: Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) Slammer actually caused many firewalls to fall over due to high pps and having to track state. I thought about posting in the super-large anti-NAT/statefull firewall thread a few weeks ago but decided it wasn't worth it to stir up trouble. Here is some trivia though: Back when Slammer hit I was working for a major NSP. I had gotten late dinner with a friend and was at his work chatting with him since he worked the night shift by himself. It became apparent that something bad was wrong with the Internet. I decided to drive to my office and attempt to do what I could to fix the issues. This was a mistake. Because of corporate reasons, my office was in a different city from the POP I connected to. I was 3 hops away from our corporate firewall, one of which was a T1. We had access lists on all the routers preventing people from getting to them from the Internet, so I thought my office was the only place I could fix the issue. Well, someone had put a SQL server in front of or behind the firewall, somewhere where it would cause fun. That DOS'd the firewall. It took 3-4 hours of hacking things to get to the inside and outside routers and put an access-list blocking SQL. Once that was done the firewall instantly got better and I was able to push changes to every 7500 in the network blocking SQL on the uplink ports. This didn't stop it everywhere because we had 12000's in the core and they didn't support ACLs on most of the interfaces we had. The access lists had to stick around for at least 6 months while the Internet patched and cleaned things up. Fun fact: the office network I was using pre-dated RFC1918 so we were using public IPs. The software firewall that fell over either did so because statefull rules were included for SQL even when they weren't needed, or it died due to pure packets/sec. Regardless, all of the switching and routing hardware around it were fine. This isn't an argument against firewalls, I'm just saying that people tend to put stock in them even when they're just adding complexity. If you have access lists blocking everything the firewall would block then you might think having both gives you defense in depth, but what it also does is gives a second place where typos or human error might cause problems. It also gives a second point of failure and (if state synchronization and load-balance/failover are added) compounded complexity. It depends on the goals you're trying to achieve. Sometimes redundant duties performed by two different groups gives you piece of mind, sometimes it's just added frustration.
Re: We hit half-million: The Cidr Report
Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. Owen On May 1, 2014, at 12:56 PM, Alain Hebert aheb...@pubnix.net wrote: Hey, I worked for them (AA) in the early 90's =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 14:07, John Souter wrote: On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John
Re: We hit half-million: The Cidr Report
On 14-05-01 14:34, Owen DeLong wrote: Believe me, I cringe every time I hear “our auditors require NAT as a security mechanism” Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? you still need to have explicit port forwarding to specific LAN side hosts (like the web server) right ? Trying to be devil's advocate here: (and discussing only incoming calls) In a NAT setup for a company, wouldn't the concept be that you explicitely have to open a few ports to specific hosts ? (for instance 80 points to the web server LAN IP address) All the rest of the gazillion ports are blocked by default since the router doesn't know to which LAN host they should go. On the other hand, for a LAN with routable IPs, by default, all ports are routed to all computers, and security then depends on ACLs or other mechanisms to implement a firewall. Auditors probably prefer architecture where everything is blocked by default and you open specific ports compared to one where everything is open by default and you then add ACLs to implement security. (Not judging whether one is better, just trying to figure out why auditors might prefer NAT). Also, home routers have NAT which is really a combo of NAT with basic firewall, so if you don't have NAT, they may equate this to not having a firewall.
Re: We hit half-million: The Cidr Report
On 5/1/2014 7:10 PM, Jean-Francois Mezei wrote: Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? you still need to have explicit port forwarding to specific LAN side hosts (like the web server) right ? Trying to be devil's advocate here: (and discussing only incoming calls) That's the problem with your devil. The first outgoing connection negates every protection you've assumed with one-to-many NAT. What you really need is a policy that says explicitly what traffic is permitted in each direction. established/new outbound is the problem in this scenario, not what internal addresses you use. On a secure server LAN, the ideal configuration for outbound would only allow connections to update servers you control, and acknowledgement traffic for protocols you are allowing inbound. In a NAT setup for a company, wouldn't the concept be that you explicitely have to open a few ports to specific hosts ? (for instance 80 points to the web server LAN IP address) All the rest of the gazillion ports are blocked by default since the router doesn't know to which LAN host they should go. On the other hand, for a LAN with routable IPs, by default, all ports are routed to all computers, and security then depends on ACLs or other mechanisms to implement a firewall. Auditors probably prefer architecture where everything is blocked by default and you open specific ports compared to one where everything is open by default and you then add ACLs to implement security. Blocked by default or allowed by default are just concepts on a firewall. People make the mistake of thinking that allowed by default is the default, but that's only true of the underlying host OS, and only if that host OS isn't hardened. Specifically, ip forwarding shouldn't be turned on until needed. Linux doesn't turn this on by default, so by default you don't permit routing no matter the source or destination IP addresses. The mistake that everyone is making is they think with NAT, secure rules are easier to write so getting the firewall online for the first time is easier, and maintaining it is easier. The problem with this statement is it's only true to a certain extent. If you care about whatever you're securing at a PCI/SOX level then NAT bought you nothing. You still need to write secure inbound and outbound rules. If whatever you're securing doesn't have to be that tightly controlled then NAT buys you a little, but it comes with a glaring false sense of security. I know at my office the IT department has dealt with several worm outbreaks that spread through email and then use the local LAN to send outbound port 25. I had to block port 25 outbound for the corporate network when it became apparent that IT was using NAT is a firewall as their security methodology. (Not judging whether one is better, just trying to figure out why auditors might prefer NAT). Also, home routers have NAT which is really a combo of NAT with basic firewall, so if you don't have NAT, they may equate this to not having a firewall. Auditors prefer NAT because everyone in the world understands security and computers on different levels. You don't know if you're getting an auditor that writes their own pen-test suites or just runs nessus and prints the results. They may have been trained by someone who developed the intuitive logical understanding that NAT systems fail-closed so they're better for defense in depth. The problem with this is, as stated above, it's not buying enough to be worth it and it causes a false sense of security. They may have even reached this conclusion themselves and it's hard to convince someone their ideas are wrong. Honestly they aren't even wrong, they're just picking a battle that shouldn't mean as much as they think it does. Ideally, your security group should have unit-tests or just a network monitoring process that nmaps from both directions. On inbound there are PCI compliance auditors that will do this for you regularly so that you can be assured the protection is still there. Outbound you need to be just as vigilant to make sure the rules are just as strict. Ultimately, things like CGNAT are completely ineffective for security because the outbound rules have to be wide open so people can use it.
Re: We hit half-million: The Cidr Report
On May 1, 2014, at 4:10 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? What happens if they approach you from behind the NAT? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: We hit half-million: The Cidr Report
On Fri, May 2, 2014 11:57 am, Fred Baker (fred) wrote: On May 1, 2014, at 4:10 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? What happens if they approach you from behind the NAT? Strikes me as a red herring; CGNat is not shifting your security boundary, wheras the typical NAT device used on a shared IPv4 connection usually does.
Re: We hit half-million: The Cidr Report
On May 1, 2014, at 4:57 PM, Fred Baker (fred) f...@cisco.com wrote: On May 1, 2014, at 4:10 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Pardon my ignorance here. But in a carrier-grade NAT implementation that serves say 5000 users, when happens when someone from the outside tries to connect to port 80 of the shared routable IP ? More to the point, your trust boundary includes 5000 people. Do you know them all? Who maintains their systems and software? Do you trust them? What happens if they approach you from behind the NAT? It’s unlikely that CGN changes this at all… Most CGN deployments will be a second layer of horror on top of the existing horrors already present. Owen
Re: We hit half-million: The Cidr Report
Security is a layered approach though. I can't recall any server or service that runs in listening state (and reachable from public address space) that hasn't had some type of remotely exploitable vulnerability. It's hard to lean on operating systems and software companies to default services to off. When you run netstat -a on a lot of operating systems there are too many things in listening state without a convincing enough reason. NAT is stateful only out of necessity but after IPv6 a small layer of security will go away but there is potentially another alternative. Scanning blocks of IPv6 addresses for valid hosts is mostly a waste of time but you could do things like looking at server logs or getting IP addresses of clients you are connected with on P2P networks. A good way to prevent that is to assign multiple IPv6 addresses to operating systems as security zones so a source address a browser or P2P client would use is not the same one with potentially remotely exploitable services running in listening state. As a bonus they should probably take it one step further and just place web browsers and email clients in a dedicated VM sandbox that can be blown out and recreated in case of infection or persistent browser toolbars and stuff. So far malware seems to be winning the war so it might be best to just acknowledge that people are likely to be attacked successfully and attempt to quarantine it when it happens. It would probably be less intrusive than trying to force people into restricted user accounts so I never understood why nobody ever really pushed for this. Technical users have been running suspect code and links in VM's for a while now. On Wed, Apr 30, 2014 at 1:13 AM, Owen DeLong o...@delong.com wrote: On Apr 29, 2014, at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”. Owen
Re: We hit half-million: The Cidr Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 29/04/2014 04:39, valdis.kletni...@vt.edu a écrit : Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? Deaggs can legitimatelly occur for a different purpose : hijack prevention (Pilosov Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. - -- Jérôme Nicolle -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNg94YACgkQbt+nwQamihvv6wCdFS6gqfUJwD0m/OelYdWjCZui S9cAnAkxlWyM4/JJmTPKxPWKYRXbz/c0 =vuYo -END PGP SIGNATURE-
Re: We hit half-million: The Cidr Report
Just out of curiosity, how does removing port address translation from the equation magically and suddenly make everything exposed, and un-invent the firewall? -Blake On Tue, Apr 29, 2014 at 11:00 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 11:37 PM, TheIpv6guy . wrote: On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?). The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago. Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks. These are ports that were originally open by default... and if you don't have a perimeter policy, you're wrong (policy, compliance, regulation, etc). Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... Jeff
Re: We hit half-million: The Cidr Report
On 4/30/14, 12:00 AM, Jeff Kell jeff-k...@utc.edu wrote: Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... This is emphatically not true. All PCI compliance requires is that your private IP addresses are not disclosed to the public, which could be RFC1918, NAT, firewalling, proxies, creative routing, etc. --Josh hates this misconception.
Re: We hit half-million: The Cidr Report
On Apr 30, 2014, at 09:15 , Jérôme Nicolle jer...@ceriz.fr wrote: Le 29/04/2014 04:39, valdis.kletni...@vt.edu a écrit : Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? Deaggs can legitimatelly occur for a different purpose : hijack prevention (Pilosov Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. The idea I have a 'reason' for hurting everyone else, so it is OK has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
RE: We hit half-million: The Cidr Report
Behalf Of Jeff Kell Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. Jamie
Re: We hit half-million: The Cidr Report
On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) pgpIfdP2icDUY.pgp Description: PGP signature
Re: We hit half-million: The Cidr Report
On 4/30/14, 9:30 AM, valdis.kletni...@vt.edu wrote: On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) So, I've been (fomerly) involved in the design/build/operation/refresh of pci environments as part of application services for enterprise with ~ order of .8 billion annually in online sales. The process starts at the beginning e.g. before you build it. If you parachute in a consultant or auditor totally cold, you are going to have to educate them to the nuances of your particular operation, it's is very similar with SOX controls. In any event your documentation should be order. and actual operation should be as documented. Ultimately as was my experience with FIPA/HERPA compliance in the educational environment these should not taken as mysterious externalities foisted on operations by hostile regulators, or industrial cartels, but as part of normal business operations, and internalized as such. signature.asc Description: OpenPGP digital signature
Re: We hit half-million: The Cidr Report
Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) In my previous jobs when I was doing FIPS/NIST/whatever compliance, it ended up being the case that having a highlighted copy of the spec document worked wonders most of the time. Barring that, the one place where I had a problem with this also had a COO who was formerly a shark-in-an-$8000-suit type of lawyer, and he was often able to explain to a clue-free auditor's boss exactly what would happen if they failed us despite the fact we met the spec as written (starting with reporting them to the PCI guys in charge of maintaining the list of qualified auditors). It's been my general experience that one must vet auditors in the same way one vets other vendors of intangible products--carefully and thoroughly, lest they screw you. Spend the same amount of energy you'd spend choosing the appropriate corporate lawyers or outsourced HR. -- Josh
Re: We hit half-million: The Cidr Report
Patrick, Le 30/04/2014 16:54, Patrick W. Gilmore a écrit : It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea. I totally agree with you. It's a shame to have to consider bad practices from a network perspective as necessities from a security standpoint. That beeing said, let's try to consider adverse interests on that matter. Large routing tables are an issue for smaller networks generating less value than major players usually providing transits to others. The constant growth of the routing table gives a technical and economical advantages to established carriers (roughly the same arguing OTTs _must_ pay premium PNIs because of an arbitrary ratio-driven peering policy). The necessity for higher-end routers to provide transit services could also slow down the steep fall of transit prices. It would establish a sensible barrier to newcomers on local transit services. It's also reducing the value of older equipments and killing the grey-market and brokers. Well, the power-draw of 6500's and other oldies could be enough, but their unability to scale to today's standards helps newer hardware sales. Now there would be a smart way to handle the issue with SDN. A smart network controler could manage a larger RIB with ease and provide routing-ASICs with a virtualy agregated FIB much smaller than the previous 256k routes limit, thus creating more interest for older routing-switches. Would a manufacturer develop such a smart conroller ? Nah, let's sell bigger overpriced TCAMs instead. Oh, and of course, the argument about hijack-prevention would disapear if everyone was doing there part and deploy RPKI in a matter of weeks. As did everyone feel the responsability to deploy IPv6, for that matter. See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. I'm not sure we're on the same page here. De-agregating with a no-export tag will have no effect at all but on TE between the orinating AS and its transit provider. If the more specific prefix isn't propagated, a hijack may occur locally anywhere else on the Internet. Let's consider someone willing to intercept mails from major hosted services (gmail, outlook...) to a company connected through bad transits. The hijacker would simply announce the more specific prefix on a few IXPs and win the reachability. The backchannel route could then be established over any other T1 (who won't pick up the more-specific anyway). Simply put, you have to be no more than one hop away from most IXPs to get a decent hijack-proof reachability. De-agg with no-export is a nonsense. The idea I have a 'reason' for hurting everyone else, so it is OK has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. Alright, let's implement new policies at a RIR, IXPs and T1s levels to forbid anyone from de-agregation without no-exports. Culprits would fall under a three-strike policy before definitive de-peering and public humiliation. Who's with me ? :) -- Jérôme Nicolle
Dealing with auditors (was Re: We hit half-million: The Cidr Report)
On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. Later years I was in a small 1100-many HP9000 shop--same thing only different. (That was also the environment with a medical school and hospital with Internet-accessible heart monitors on Windows 95.) I think there has been some drift away from IBMishness as The Gold Standard, but it still looks like there is no allowance for the real world in computing and networking. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
The auditors VMware sent to us were just as bad. To ensure we weren't running rogue ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. Oh look, this MAC isn't listed as one of your virtual machines. It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC On Wed, Apr 30, 2014 at 2:31 PM, William Herrin b...@herrin.us wrote: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html
RE: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
We just dealt with a vmware audit too; it was a joke. In any case, the thing I found curious with their auditor as well as a PCI QSA (fancy auditor), is that neither entity seemed to know IPv6 exists. The whole time I'm thinking okay, now why aren't you investigating these same attack vectors in IPv6? Just another reason PCI is not necessarily about security David -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ulf Zimmermann Sent: Wednesday, April 30, 2014 8:36 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report) The auditors VMware sent to us were just as bad. To ensure we weren't running rogue ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. Oh look, this MAC isn't listed as one of your virtual machines. It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC On Wed, Apr 30, 2014 at 2:31 PM, William Herrin b...@herrin.us wrote: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html
Re: We hit half-million: The Cidr Report
On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff
Re: We hit half-million: The Cidr Report
The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has use as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: What's 3 extra prefixes in half a million? The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning lots lots.) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, your network is part of the community, and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston g...@apnic.net wrote: On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff
RE: We hit half-million: The Cidr Report
Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has use as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: What's 3 extra prefixes in half a million? The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning lots lots.) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, your network is part of the community, and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston g...@apnic.net wrote: On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff
Re: We hit half-million: The Cidr Report
At one time Covad stated they announce everything as /24 to make hijacking more difficult. Looks like Covad (now MEGAPATH) hasn't changed that policy. On 4/29/2014 12:29 PM, Kate Gerry wrote: Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has use as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: What's 3 extra prefixes in half a million? The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning lots lots.) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, your network is part of the community, and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston g...@apnic.net wrote: On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff
Re: We hit half-million: The Cidr Report
There are many actually doing this, to be honest. From the top of my head, in the greater Dallas area, 54540 comes to mind. http://bgp.he.net/AS54540#_asinfo For large ASNs like these, aggregation would really help the table size. That said, working on reducing our own as well. On 4/29/2014 10:29 PM, Kate Gerry wrote: Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has use as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: What's 3 extra prefixes in half a million? The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning lots lots.) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, your network is part of the community, and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston g...@apnic.net wrote: On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable
Re: We hit half-million: The Cidr Report
On Apr 28, 2014, at 6:59 PM, Patrick W. Gilmore patr...@ianai.net wrote: Composed on a virtual keyboard, please forgive typos. On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: now aggregate it back down again, please. :-) I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Owen
Re: We hit half-million: The Cidr Report
On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it)
Re: We hit half-million: The Cidr Report
On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Windows XP SP3 with a default host firewall on really did solve most of this, not NAT. Not stateful firewalls in networks. In fact, jogging my memory, i clearly remember Blaster taking out enterprise networks with network firewalls and stateful inspection... because people manually move their laptops between security zones. Right? They got infected on one LAN and then attached and spread the worm to other LANs. I also remember the folks saying we just spent $100k on a pair of super Netscreen firewalls, why is our network crashing? Right? And then the infection scanning from hacked hosts... of course, overloaded the firewall, and that crashed the entire campus... because the firewall was a single point of failure sitting on the internet boarder... and it has the 0-day flaw of too many sessions = crash. Most firewalls have this 0-day, it's a feature. This really happened to me in 2003, where a network based attack had a broad impact on hosts. But, never again after Win XP SP3. Now, i just have DDoS from purposefully publicly (poorly) run NTP and DNS servers. And, hacks from users clicking on links they know they should not click on. Oh, and anything made with Java or Adobe or IE. Those things are impossible to run securely, so secure systems don't run them. And, every now and then a server gets cracked, right through the stateful firewall... because there was a rule allowing ANY to TCP 80. CB
Re: We hit half-million: The Cidr Report
On 4/29/2014 11:37 PM, TheIpv6guy . wrote: On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?). The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago. Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks. These are ports that were originally open by default... and if you don't have a perimeter policy, you're wrong (policy, compliance, regulation, etc). Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... Jeff
Re: We hit half-million: The Cidr Report
On Apr 29, 2014, at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”. Owen
RE: We hit half-million: The Cidr Report
Hi, Patrick wrote: 25-04-14500177 282878 I think congratulations are still in order, but frankly, I am less impressed with getting to 500 than 150. [...] Anyway, congratulations everyone. now aggregate it back down again, please. :-) (If only) Andy
Re: We hit half-million: The Cidr Report
On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: now aggregate it back down again, please. :-) I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. --Chris
Re: We hit half-million: The Cidr Report
Composed on a virtual keyboard, please forgive typos. On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: now aggregate it back down again, please. :-) I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. -- TTFN, patrick
Re: We hit half-million: The Cidr Report
On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? pgpWC3rGBwikB.pgp Description: PGP signature
Re: We hit half-million: The Cidr Report
On Mon, Apr 28, 2014 at 10:39 PM, valdis.kletni...@vt.edu wrote: On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said: On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote: I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? And of those TE routes, how many can be suppressed by way of BGP Communities with their respective upstream providers ... charles
We hit half-million: The Cidr Report
25-04-14500177 282878
Half a million prefixes. 'Wow .. just wow.' There was a time when even I would
have laughed at the thought of 500K.
Just a round number, but a milestone nonetheless.
I checked, back in 2004, a little under 10 years ago, I posted this to NANOG:
Patrick W Gilmore | 5 Nov 14:39 2004
On Nov 5, 2004, at 6:00 AM, cidr-report at potaroo.net wrote:
Recent Table History
Date PrefixesCIDR Agg
[...]
05-11-04156315 103781
Well, we broke 150K prefixes - and without someone deaggregating the
classical B space. :) Impressive.
Remember when the 'Net was supposed to have fallen over before now?
Pat yourselves on the back everyone, you did the impossible.
Congratulations are in order.
I think congratulations are still in order, but frankly, I am less impressed
with getting to 500 than 150. The equipment today just seems to be better able
to handle it (even with the Sup720-pocolypse), which is a good thing given our
possible de-aggregate future.
Anyway, congratulations everyone. The Internet is such an important part of not
just our lives, but literally the whole planet - every industry, every country,
every economy, every, uh, everything. And as sappy as it sounds, it has made an
immeasurable number of people's lives better.
Hopefully people won't take this the wrong way: I am proud of all of you. Keep
up the good work.
--
TTFN,
patrick
On Apr 25, 2014, at 18:00 , cidr-rep...@potaroo.net wrote:
This report has been generated at Fri Apr 25 21:13:54 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
18-04-14499254 282312
19-04-14499492 282427
20-04-14499557 282428
21-04-14499371 282193
22-04-14499156 282325
23-04-14499260 282597
24-04-14499642 282663
25-04-14500177 282878
AS Summary
46910 Number of ASes in routing system
19117 Number of ASes announcing only one prefix
3731 Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.,BR
119976960 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 25Apr14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 500075 282843 21723243.4% All ASes
AS28573 3731 380 335189.8% NET Serviços de Comunicação
S.A.,BR
AS6389 2983 58 292598.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2799 251 254891.0% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS4766 2953 931 202268.5% KIXS-AS-KR Korea Telecom,KR
AS18881 1932 37 189598.1% Global Village Telecom,BR
AS1785 2196 490 170677.7% AS-PAETEC-NET - PaeTec
Communications, Inc.,US
AS10620 2844 1349 149552.6% Telmex Colombia S.A.,CO
AS18566 2047 565 148272.4% MEGAPATH5-US - MegaPath
Corporation,US
AS36998 1634 161 147390.1% SDN-MOBITEL,SD
AS22773 3057 1587 147048.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS4323 2937 1516 142148.4% TWTC - tw telecom holdings,
inc.,US
AS7303 1757 457 130074.0% Telecom Argentina S.A.,AR
AS4755 1850 583 126768.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS7545 2228 1072 115651.9% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS7552 1220 107 111391.2% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1301 241 106081.5% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS6983 1326 314 101276.3% ITCDELTA -
