Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
As of 38.0.5, this no longer is even an option, as they removed sslv3 support, see the reviews at https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/ On Fri, July 17, 2015 2:41 pm, Robert Drake wrote: On 7/17/2015 4:26 AM, Alexander Maassen wrote: Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The fix was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff. https://support.mozilla.org/en-US/questions/1042061
Re: another tilt at the Verizon FIOS IPv6 windmill
On 7/17/15, 6:25 AM, Christopher Morrow christopher.mor...@gmail.com on behalf of morrowc.li...@gmail.com wrote: On Wed, Jul 15, 2015 at 4:43 PM, Ricky Beam jfb...@gmail.com wrote: On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard l...@asgard.org wrote: Business Class DOCSIS customers get a prefix automatically (unless you provide your own gateway and DHCPv6 isn¹t enabled). doesn't the last paranthetical here I looked last night at the office in Cary, NC. NO RAs are seen on the link coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. Without an RA, nothing will attempt IPv6. mean that your UBee has to do dhcpv6? (or the downstream thingy from the UBee has to do dhcpv6?) Yes. I should have said that there are some modems that don’t support IPv6, and a few that should-but-don’t-properly-yet. Ricky and I have corresponded privately. Lee (I've not checked the one in Raleigh that's also a hotspot) Residential? sure, there's lot of v6 there -- has been for over a year. But as I'm an Earthlink customer, and those morons cannot be bothered to give TWC one of their *5* UNUSED /32's, all I get is: (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) --Ricky
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On 7/17/2015 4:26 AM, Alexander Maassen wrote: Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The fix was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff. https://support.mozilla.org/en-US/questions/1042061
RE: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
After making the about:config changes, no warning is given to the user about the bad ciphers. Even if you click the SSL lock icon, no warning is given. Only if you know that the connection being made with TLS_RSA_WITH_AES_128_CBC_SHA,128 bit keys, TLS 1.0 is a bad thing would you have any clue. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Robert Drake Sent: Friday, July 17, 2015 8:42 AM To: nanog@nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers On 7/17/2015 4:26 AM, Alexander Maassen wrote: Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The fix was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. The long term fix is to get new hardware and run it all in virtual machines with new software on top, but that may be in next years budget. I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. Having said that, it seems that there is a workaround in Firefox if people need it. about:config and re-enabling the weak ciphers. Hopefully turning them on leaves you with a even bigger warning than normal saying it's a bad cert, but you could get back in. This doesn't help my coworkers. I'm not going to advise a bunch of people with varying levels of technical competency to turn on weak ciphers, but it does help with a situation like yours where you absolutely can't update old DRAC stuff. https://support.mozilla.org/en-US/questions/1042061
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On 07/17/2015 08:41 AM, Robert Drake wrote: I've also got a jetty server (opennms) that broke due to this, so I upgraded and fixed the SSL options and it's still broken in some way that won't log errors. I have no time to track that down so the workaround is to use the unencrypted version until I can figure it out. We had a ticket about this a couple weeks ago from a support client who was catching flak from a PCI-DSS audit team. Here's the changeset that should address the problem: https://github.com/OpenNMS/opennms/commit/6da9e8952e7f81b0b863da93add684c5e963e0ba -jeff signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 9:10 AM, John R. Levine wrote: It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4. There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet. In IPv4 systems, the problem is (so I have been told by some largish ISPs) that a dual homed customer gets address ranges from ISPs A and B, and sends traffic with A addresses to the B interface. The ISPs have no practical way to tell legit dual homed traffic from malicious, particularly when there is a chain of resellers in between. If the ISP tells the customer to send the traffic over the right interface, the usual response is if you don't want our business, I'm sure we can find another ISP that does. Strict rpf has the super nice property that if you withdraw you prefix from a peer, that peer blackholes traffic. there are all sorts of fun cases like for example MLPE peering on exchange fabrics where you can't just tag the prefix no export and send it to your neighbor, which means it's all or nothing. The exigent reality is that the less control customers have over their own policy then the easier they are to filter. retail isp customers with prefixes delegated by their provider, easy so when ISPS practice good hygiene on their retail side, great.. some dude at an exchange point direct adjacency or no, quite a bit harder. Like I said, it would be nice if ISPs could persuade their v6 customers to get their own PI space early on, because if they don't they'll have exactly the same problem. R's, John signature.asc Description: OpenPGP digital signature
Re: NANOG Digest, Vol 90, Issue 1
To Ramy, Thank you for the acknowledgement. DDoS Mitigation service providers, regardless if its pure cloud, hybrid cloud, or CPE only, all face these challenges when it comes to DDoS Attacks. Can you restate your question again or rephrase it for the forum? Seems there is some confusion or maybe people didn't grasp it. My understanding of the question RAMY asked was around DDoS mitigation providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do businesses protect themselves when attack traffic is NOT stopped at first?.IE: Defense in depth NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's. Its all moot though. These types of solutions do not guarantee up time during the initial attack start time, PERIOD! How can anyone guarantee up-time during a 40Gbps attack and lets say - all you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having larger port capacity (IE: 10GB ports) only gives you minutes/hours to react and redirect to a Cloud Provider. The time to start mitigation (average industry time) 30 - 45 minutes. What is happening to your WAN infrastructure when there is 40Gbps of attack on your doorstep. Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it will get saturated, BGP will flap and any GRE connections or any other traffic will be lost. This means, even with local CPE mitigation, things will bounce. This is 1 scenario of 1000's. There are positive security models that you can employ as as stop gap to prevent these types of scenario's, but mostly its on the Service Providers best practices or traffic posture model. IE: On-Demand, On-Demand with monitoring, Always-On monitoring, Always-On monitoring and mitigation. Having local mitigation for DDoS attacks is a loosing battle in my opinion. Its only buying you time to redirect. It does solve problems like attacks that are low in scale that you can consume with your port capacity or quick to hit and run attacks (1-2min durations). But then you need auto-mitigation enabled and that leads to collateral damage most of the times for legitimate traffic. Pretty sure other SP's will offer different opinion. This is my technical opinion, not representing Akamai or any other companies official position. From an engineering perspective, assume when an advisory targets your business and they have 1/2 way decent attacking nodes, expect an outage. Message that to the board but explain that you have every capability to mitigate these risks. Given the SP you go with has enough staff, resources, capacity, technology, SLA, and knowledge/experience in the attack vector hitting you. If you want to learn more, keep up the engagements with the market DDoS providers you are communicating with and ask these tough questions. If anyone sells you the perfect solution, they are LIEING to you! On a personal note, thank you for reaching out privately in email and explaining who you are talking too. Trust me when I tell you, I know the organization VERY WELL from the other competitor you are looking at and i will offer you my candid opinion of them, if you'd like. My friend runs their SOC over there, an old colleague of mine from when i was in the SOC blocking attacks. Love this topic! Dennis On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins rdobb...@arbor.net wrote: On 8 Jul 2015, at 22:26, Roland Dobbins wrote: Hardware-based GRE processing is required on both ends for anything other than trivial speeds; in general, the day of software-based Internet routers is long gone, and any organization still running software-based routers on their transit/peering edges at risk. To clarify, I'm referring to GRE processing on routers; hardware processing is pretty much a requirement on routers. Other types of devices can often handle GRE at significantly higher rates than software-based routers. --- Roland Dobbins rdobb...@arbor.net
Prefix-Hijack by AS7514
Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: Prefix-Hijack by AS7514
Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
AW: Prefix-Hijack by AS7514
We already informed AS2497 but I have no idea if they we'll cooperate. Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: AW: AW: Prefix-Hijack by AS7514
I let IIJ know too, hopefully they'll filter it soon. On 7/17/2015 午後 03:30, Jürgen Jaritsch wrote: Hi, we also sent them an mail, but their MX is not reachable for us :( best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp] Gesendet: Freitag, 17. Juli 2015 08:29 An: Jürgen Jaritsch j...@anexia.at; Hugo Slabbert hslabb...@stargate.ca Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: AW: Prefix-Hijack by AS7514 I contacted 7514. They are aware. -Seiichi On 2015/07/17 15:23, Jürgen Jaritsch wrote: We already informed AS2497 but I have no idea if they we'll cooperate. Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: ISP in NYC
good isp's / peers are in no particular order bt telstra ex psinet uk/eu colin Sent from my iPhone On 17 Jul 2015, at 07:52, Jared Geiger ja...@compuwizz.net wrote: HE uses Telia for Transit. So you won't gain much redundancy there. I would go with Cogent if you have lots of European customers and North American business customers. One not on your list is Level3. They would be strong in that blend too. You might also try joining a peering point. You'll gain a lot by just peering with the route servers. On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender do...@telecurve.com wrote: Hi, We are looking to peer with another ISP in NY. My options are: Telia Tata Cogent We currently have (and will keep): HE NTT TELX (They use NTT and HE and we are looking to replace them). We need an ISP that has a good peering/connectivity in Europe and Asia (Israel specific). Any advice on who to go with?
RE: Remember Internet-In-A-Box?
Ricky Beamwrote: On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews ma...@isc.org wrote: You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's. I blame the anti-DHCP crowd for a lot of things. RAs are just dumb. There's a reason IPv4 can do *everything* through DHCP -- hell, even boot menu lists are sent in dhcp pakcets. The reason is that DHC was the longest lived working group in IETF history. It took over 15 years of changes to get what you consider a working implementation. At the point the IPv6 RA was specified, it was very difficult for people to get addressing and routers consistently configured via dhcp, let alone everything else that was added. The XP box is in an even worse situation if you try to run it on a v6-only network. Which is fixable with a third party DHCPv6 client / manual configuration of the nameservers. Just like no IP stack was fixable in the 80's. No. Just, No. There are millions upon millions of internet users I wouldn't trust to double click setup.exe. None of which is the fault of the protocol. Actually, it's 100% the fault of the protocol. IPv6-only networking has been a cluster-f*** from day one. And it still doesn't f'ing work today. Until there is *A* standard to implement, that stands still for more than an hour before something else critical gets bolted on to it, people are going to continue to ignore IPv6. So if you want to wait for a stable specification, why did you ever implement IPv4? Here we are 35+ years later and there are still changes to the base IPv4 header in the works. http://tools.ietf.org/rfcmarkup?doc=draft-dreibholz-ipv4-flowlabel How could anyone ever implement a target that has continued to move for that long a period? With over 5,000 documents describing the continuous changes to IPv4, there is obviously A standard to implement in there somewhere. Clearly some people have figured out how to deploy IPv6, but if you want to wait, that is your choice. Yes, my XP machines work fine with IPv6... on a network using SLAAC, where IPv4 (DHCPv4) is still enabled and providing the various bits necessary to do anything other than ping my gateway. The XP implementation was never expected to last as long as it did, The delay in shipping the Vista/W7 stack resulted in quite a bit of functionality being late. The entire point of the XP implementation was to put a working API in the hands of app developers. It was never intended to be used in IPv6-only networks 15 years after its release. Tony
Re: ISP in NYC
Rather than a peer, it might be an okay idea to try out peering at NYIIX (and if the funds permit to get transport, AMS-IX/DE-CIX). You'll quickly find that peering is *very* useful in Europe, if you have any EU bound traffic at all. On 7/17/2015 午後 04:06, Colin Johnston wrote: good isp's / peers are in no particular order bt telstra ex psinet uk/eu colin Sent from my iPhone On 17 Jul 2015, at 07:52, Jared Geiger ja...@compuwizz.net wrote: HE uses Telia for Transit. So you won't gain much redundancy there. I would go with Cogent if you have lots of European customers and North American business customers. One not on your list is Level3. They would be strong in that blend too. You might also try joining a peering point. You'll gain a lot by just peering with the route servers. On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender do...@telecurve.com wrote: Hi, We are looking to peer with another ISP in NY. My options are: Telia Tata Cogent We currently have (and will keep): HE NTT TELX (They use NTT and HE and we are looking to replace them). We need an ISP that has a good peering/connectivity in Europe and Asia (Israel specific). Any advice on who to go with?
Re: AW: AW: Prefix-Hijack by AS7514
Date: Fri, 17 Jul 2015 15:38:13 +0900 Paul S. cont...@winterei.se wrote I let IIJ know too, hopefully they'll filter it soon. It seems AS7514 stopped the announcements around 06:54UTC. I am not sure how BGPmon guesses AS relationships, but it needs improvements as it shows IIJ as an upstream of AS7514 wrongly. - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
AW: AW: Prefix-Hijack by AS7514
Hi, we also sent them an mail, but their MX is not reachable for us :( best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Seiichi Kawamura [mailto:kawamu...@mesh.ad.jp] Gesendet: Freitag, 17. Juli 2015 08:29 An: Jürgen Jaritsch j...@anexia.at; Hugo Slabbert hslabb...@stargate.ca Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: AW: Prefix-Hijack by AS7514 I contacted 7514. They are aware. -Seiichi On 2015/07/17 15:23, Jürgen Jaritsch wrote: We already informed AS2497 but I have no idea if they we'll cooperate. Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
AW: AW: Prefix-Hijack by AS7514
Hi, all affected prefixes starts with 37... no other prefixes from AS42473 are affected. Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hank Nussbacher [mailto:h...@efes.iucc.ac.il] Gesendet: Freitag, 17. Juli 2015 08:33 An: Jürgen Jaritsch j...@anexia.at; Hugo Slabbert hslabb...@stargate.ca Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: AW: Prefix-Hijack by AS7514 At 06:23 17/07/2015 +, Jürgen Jaritsch wrote: We already informed AS2497 but I have no idea if they we'll cooperate. All prefixes I see have the first octet as being 2 digits rather than 3. That is common among about 30 different alerts I have received. Curious if this is common worldwide. -Hank Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: ISP in NYC
HE uses Telia for Transit. So you won't gain much redundancy there. I would go with Cogent if you have lots of European customers and North American business customers. One not on your list is Level3. They would be strong in that blend too. You might also try joining a peering point. You'll gain a lot by just peering with the route servers. On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender do...@telecurve.com wrote: Hi, We are looking to peer with another ISP in NY. My options are: Telia Tata Cogent We currently have (and will keep): HE NTT TELX (They use NTT and HE and we are looking to replace them). We need an ISP that has a good peering/connectivity in Europe and Asia (Israel specific). Any advice on who to go with?
Re: AW: AW: Prefix-Hijack by AS7514
any idea why error happened ? what config needs fixing to mitigate mistake? it was easy to see problem via ripe atlas :) colin Sent from my iPhone On 17 Jul 2015, at 09:32, Matsuzaki Yoshinobu m...@iij.ad.jp wrote: Date: Fri, 17 Jul 2015 15:38:13 +0900 Paul S. cont...@winterei.se wrote I let IIJ know too, hopefully they'll filter it soon. It seems AS7514 stopped the announcements around 06:54UTC. I am not sure how BGPmon guesses AS relationships, but it needs improvements as it shows IIJ as an upstream of AS7514 wrongly. - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
Re: Prefix-Hijack by AS7514
At 06:15 17/07/2015 +, Jürgen Jaritsch wrote: Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Worldwide. -Hank Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: AW: AW: Prefix-Hijack by AS7514
Colin Johnston col...@gt86car.org.uk wrote any idea why error happened ? what config needs fixing to mitigate mistake? it was easy to see problem via ripe atlas :) I just got brief explanation from a friend in AS7514. A router in their network suddenly went out of control, and it seems this somehow generated wrong routing information. They solved the issue by disconnecting the router and are now investigating it. - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
Re: AW: Prefix-Hijack by AS7514
At 06:23 17/07/2015 +, Jürgen Jaritsch wrote: We already informed AS2497 but I have no idea if they we'll cooperate. All prefixes I see have the first octet as being 2 digits rather than 3. That is common among about 30 different alerts I have received. Curious if this is common worldwide. -Hank Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
many web sites are gonna have to upgrade ciphers and get rid of flash. this will take vastly longer than prudence would dictate. randy
Re: AW: Prefix-Hijack by AS7514
I contacted 7514. They are aware. -Seiichi On 2015/07/17 15:23, Jürgen Jaritsch wrote: We already informed AS2497 but I have no idea if they we'll cooperate. Best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: Hugo Slabbert [mailto:hslabb...@stargate.ca] Gesendet: Freitag, 17. Juli 2015 08:23 An: Jürgen Jaritsch j...@anexia.at Cc: 'nanog@nanog.org' nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 Seeing the same; a /19. BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497. -- Hugo Slabbert Stargate Connections - AS19171 -Original Message- Date: Fri, 17 Jul 2015 06:15:36 + From: Jürgen Jaritsch j...@anexia.at To: 'nanog@nanog.org' nanog@nanog.org Subject: Prefix-Hijack by AS7514 Hi, does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 Thanks best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.atmailto:j...@anexia.at Web: http://www.anexia.athttp://www.anexia.at/ Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Re: ISP in NYC
Hibernia (5580) have good latency throughout Europe and are huge on AMS-IX. Latency is around 18ms from Edinburgh to Amsterdam and 5ms from London via their network. Used them for transit and they gave me a circuit onto AMS-IX too which could be worth you looking into. Between the route servers and peers on the exchange I was getting ~210k routes. On 17 Jul 2015 08:22, Paul S. cont...@winterei.se wrote: Rather than a peer, it might be an okay idea to try out peering at NYIIX (and if the funds permit to get transport, AMS-IX/DE-CIX). You'll quickly find that peering is *very* useful in Europe, if you have any EU bound traffic at all. On 7/17/2015 午後 04:06, Colin Johnston wrote: good isp's / peers are in no particular order bt telstra ex psinet uk/eu colin Sent from my iPhone On 17 Jul 2015, at 07:52, Jared Geiger ja...@compuwizz.net wrote: HE uses Telia for Transit. So you won't gain much redundancy there. I would go with Cogent if you have lots of European customers and North American business customers. One not on your list is Level3. They would be strong in that blend too. You might also try joining a peering point. You'll gain a lot by just peering with the route servers. On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender do...@telecurve.com wrote: Hi, We are looking to peer with another ISP in NY. My options are: Telia Tata Cogent We currently have (and will keep): HE NTT TELX (They use NTT and HE and we are looking to replace them). We need an ISP that has a good peering/connectivity in Europe and Asia (Israel specific). Any advice on who to go with?
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. On Fri, July 17, 2015 10:14 am, Randy Bush wrote: many web sites are gonna have to upgrade ciphers and get rid of flash. this will take vastly longer than prudence would dictate. randy
Re: Dual stack IPv6 for IPv4 depletion
Dictatorship enabled by consensus == Democratic Republic, Welcome to America! On 7/17/15 12:17 PM, Joe Maimon wrote: Owen DeLong wrote: On Jul 16, 2015, at 15:29 , Joe Maimon jmai...@ttec.com wrote: All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. Sometimes good leadership is knowing when to say “not just no, but hell no.” Owen This is not one of them. Your stated reason for hell no is that you want no distractions from ipv6 rollout. That is not leadership. That is dictatorship via tyranny of the minority, enabled by consensus, Joe
Re: Dual stack IPv6 for IPv4 depletion
Lee Howard wrote: On 7/16/15, 4:32 PM, Joe Maimon jmai...@ttec.com wrote: Lee Howard wrote: So, you would like to update RFC 1112, which defines and reserves Class E? That¹s easy enough. If somebody had a use in mind for the space, anybody can write such a draft assigning space, which is, I believe, how to direct IANA to do something with it. nope “Nope?” Nope, there were previous attempts that failed and the task was not easy enough, unnecessarily so. You mean you don’t want to update RFC1112? Or it’s not possible for somebody to write a draft telling IANA to assign space for an experiment? Somebody has to write a draft in order for the IETF to consider it, Which has happened. and there has to be IETF consensus for it to get published as an RFC. Which did not happen, due in no small part, I allege, to spurious and specious concerns about ipv6 adoption and to to irrelevant and misprojected concerns as to whether it was worth it. I don’t see the relevance. Nobody there proposed reclassifying the space. Nobody had a proposal for an experiment. Nobody wanted an assignment from it. Quoted directly there is an I-D to utilize at least some portion of the space for what we later allocated public unicast /10 Carrier private. The only use I have in mind for the space is for it to cease being classified as experimental and therefore treated as invalid. You want the word “RESERVED” for some entries on this page changed: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml What do you want it changed to? Personally, a /6 of LSN/CGN private, /8 (per rir?) of public early adopter by the /16, and the rest reserved for if/when it ever becomes A) more useful and/or B) rehabilitated, /8 per rir. But I would get behind any effort for any status that would indicate proper behavior for any/and all new updated stacks is to allow its use without differentiation. There’s more to it than that. How would people who want to use it get assignments? Right now, there’s no policy for assigning that space. The first stop is to change the standard so that considering the address illegal to use in software could be considered improper behavior. If the community cant even get past that, and they have not in the past, no other scheme stands a chance. Tying objections to removing that barrier due to lack of a fully acceptable allocation policy is unnecessarily inflating the hurdle to that goal. You’ve told other people that there shouldn’t be a top-down restriction on this space; but there’s no top: it’s all consensus. The consensus here is very clear. You are welcome to try to change it, and a couple of us are trying to should you the processes (IETF, IANA, RIR) to do that. My categorization as inappropriate top down restrictions is specifically calling out those who believe policy is a tool to direct and marshal other peoples efforts, away from what they consider competing goals. I dont consider that a valid rational and I think its quite inappropriate. If all you want to do is vent, we’ll just move on to another thread. Lee Venting is a form of consensus building. If there are any drafts anywhere that could use some of that, please point them out. Joe
Re: Dual stack IPv6 for IPv4 depletion
Baldur Norddahl wrote: On 17 July 2015 at 00:29, Joe Maimon jmai...@ttec.com wrote: All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. If I understand correctly you want someone (not you) to write a RFC that changes the word experimental to something else. Yes. Even me. But you do not want IANA and the 5 RIRs to implement policies to hand out this space. I dont consider that a necessary part of status change. Nor do you expect any vendor to change anything? I dont expect them to change anything unless experimental/reserved for future potentially non-unicast protocol behavior is removed from IETF standards. May i then suggest that something else could be junk or useless ? Which would still render software that refused to allow use of the space non standards compliant, so I can accept that as a starting basis. Fact is that it is junk. It is probably not even routable in the default free zone. Anyone up for an experiment? Probably need to change the standards first. Nobody is going to want a class E address. Even if your own equipment was updated to allow it, you would not be able to communicate with most of the internet. Tell me, in what timeframe do you expect that would change, if someone did write that RFC and got it approved? A lot sooner if people would stop complaining that it takes too long. Otherwise, never. You got it all wrong when you believe it is a top down decision. It is the opposite. You are fighting _consensus_. Nobody wants to change the status of class E because it would not work and would only confuse. Regards, Baldur Plenty of people want(ed) to change the status. The objections of the naysayers amount(ed) to, we think it will take too long to be usable in equivalent fashion to current unicast, and we think if it ever is usable it wont be enough of a difference to have made it worth it and we want ipv6 instead so we dont want anyone to even try. Even if all those objections are valid, they still do not justify doing nothing. Joe
Re: another tilt at the Verizon FIOS IPv6 windmill
On Wed, Jul 15, 2015 at 4:43 PM, Ricky Beam jfb...@gmail.com wrote: On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard l...@asgard.org wrote: Business Class DOCSIS customers get a prefix automatically (unless you provide your own gateway and DHCPv6 isn¹t enabled). doesn't the last paranthetical here I looked last night at the office in Cary, NC. NO RAs are seen on the link coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. Without an RA, nothing will attempt IPv6. mean that your UBee has to do dhcpv6? (or the downstream thingy from the UBee has to do dhcpv6?) (I've not checked the one in Raleigh that's also a hotspot) Residential? sure, there's lot of v6 there -- has been for over a year. But as I'm an Earthlink customer, and those morons cannot be bothered to give TWC one of their *5* UNUSED /32's, all I get is: (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) --Ricky
Re: AW: AW: Prefix-Hijack by AS7514
even if customer router crash fault, should have been filtered via prefix list blocking to only allow customer network prefixs to be anounced onwards ? as per best practice colin Sent from my iPhone On 17 Jul 2015, at 09:55, Matsuzaki Yoshinobu m...@iij.ad.jp wrote: Colin Johnston col...@gt86car.org.uk wrote any idea why error happened ? what config needs fixing to mitigate mistake? it was easy to see problem via ripe atlas :) I just got brief explanation from a friend in AS7514. A router in their network suddenly went out of control, and it seems this somehow generated wrong routing information. They solved the issue by disconnecting the router and are now investigating it. - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
Re: AW: AW: Prefix-Hijack by AS7514
On 17/Jul/15 11:46, Matsuzaki Yoshinobu wrote: Yes, I agree, and we have done that. How about peering partners - which is our case this time. Is it feasible to maintain strict inbound prefix filters for all peering relationships? To be honest, not really. Some countries I know do this for their exchange points. But by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. One can be liberal at peering points but have max-prefix as a basic protection mechanism (which is what we do). Of course, IRR's are the other way to go. Mark.
Re: Prefix-Hijack by AS7514
On 17.07.2015, at 12:03, Mark Tinka mark.ti...@seacom.mu wrote: Some countries I know do this for their exchange points. But by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. (And: we are not a country but an exchange point operator :-) best regards Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.trem...@de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln
Re: Prefix-Hijack by AS7514
On 17/Jul/15 12:47, Wolfgang Tremmel wrote: it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. So you have prefix and AS_PATH lists for each of the members you peer with that strictly define the prefixes they will announce to your route server? (And: we are not a country but an exchange point operator :-) One learns something new everyday... Mark.
AW: Prefix-Hijack by AS7514
Wolfgang, it's unfair ... you do not have to deal with hardware routers :). Install AS_PATH ACL and prefix list on a Cisco router (e.g. with an RSP720-3CXL) and you'll run into lots of pain ... best regards Jürgen Jaritsch Head of Network Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: NANOG [mailto:nanog-boun...@nanog.org] Im Auftrag von Wolfgang Tremmel Gesendet: Freitag, 17. Juli 2015 12:48 An: nanog@nanog.org Betreff: Re: Prefix-Hijack by AS7514 On 17.07.2015, at 12:03, Mark Tinka mark.ti...@seacom.mu wrote: Some countries I know do this for their exchange points. But by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. (And: we are not a country but an exchange point operator :-) best regards Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.trem...@de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln
Re: AW: AW: Prefix-Hijack by AS7514
Colin Johnston col...@gt86car.org.uk wrote even if customer router crash fault, should have been filtered via prefix list blocking to only allow customer network prefixs to be anounced onwards ? as per best practice Yes, I agree, and we have done that. How about peering partners - which is our case this time. Is it feasible to maintain strict inbound prefix filters for all peering relationships? - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
Re: Remember Internet-In-A-Box?
On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote: * Owen DeLong o...@delong.com On Jul 15, 2015, at 08:57 , Matthew Kaufman matt...@matthew.at wrote: This is only true for dual-stacked networks. I just tried to set up an IPv6-only WiFi network at my house recently, and it was a total fail due to non-implementation of relatively new standards... starting with the fact that my Juniper SRX doesn't run a load new enough to include RDNSS information in RAs, and some of the devices I wanted to test with (Android tablets) won't do DHCPv6. That’s a pretty old load then, as I’ve had RDNSS on my SRX-100 for several years now. Interesting. Which JUNOS version are you running, exactly? According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, which isn't available for the SRX series (nor is any later version). http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html Strange. dns-server-address IS available to be configured on my MX box running 13.3R4. It is however not there for SRX on 12.1X44-D50.
Re: Remember Internet-In-A-Box?
On Fri 2015-Jul-17 12:36:51 -0400, Chuck Anderson c...@wpi.edu wrote: On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote: * Owen DeLong o...@delong.com On Jul 15, 2015, at 08:57 , Matthew Kaufman matt...@matthew.at wrote: This is only true for dual-stacked networks. I just tried to set up an IPv6-only WiFi network at my house recently, and it was a total fail due to non-implementation of relatively new standards... starting with the fact that my Juniper SRX doesn't run a load new enough to include RDNSS information in RAs, and some of the devices I wanted to test with (Android tablets) won't do DHCPv6. That’s a pretty old load then, as I’ve had RDNSS on my SRX-100 for several years now. Interesting. Which JUNOS version are you running, exactly? According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, which isn't available for the SRX series (nor is any later version). http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html Strange. dns-server-address IS available to be configured on my MX box running 13.3R4. It is however not there for SRX on 12.1X44-D50. ...or 12.1X46-D35.1 (JTAC bumped the rec'd release June 29th, so it's in the lab). -- Hugo h...@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure redphone) signature.asc Description: Digital signature
Re: Prefix-Hijack by AS7514
On Fri, Jul 17, 2015 at 10:47:38AM +, Wolfgang Tremmel wrote: On 17.07.2015, at 12:03, Mark Tinka mark.ti...@seacom.mu wrote: Some countries I know do this for their exchange points. But by-and-large, it is not scalable. Same goes for AS_PATH lists for peering. it does scale. We do this for all our routeservers at all exchange points we operate. In Frankfurt we have 745 peers on our routeservers. Scale has become my favorite term from vendors that sets off alarm bells. The problem is usually limited by someones imagination like why would you have more than 1 comment/remark, or what do you mean a customer has 200k prefixes registered. it all depends on who/where and what role you play. We have tried prefix filtering peers before. It's an excercise in frustration when it comes to vendors ability to ingest the large sets and/or changes. I talked about this privately and at things like IEPG. http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf The situation and technology haven't substantively changed in the interim. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Dual stack IPv6 for IPv4 depletion
Owen DeLong wrote: On Jul 16, 2015, at 15:29 , Joe Maimon jmai...@ttec.com wrote: All I am advocating is that if ever another draft standard comes along to enable people to try and make something of it, lead follow or get out of the way. Sometimes good leadership is knowing when to say “not just no, but hell no.” Owen This is not one of them. Your stated reason for hell no is that you want no distractions from ipv6 rollout. That is not leadership. That is dictatorship via tyranny of the minority, enabled by consensus, Joe
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Robert Drake rdr...@direcpath.com writes: On 7/17/2015 4:26 AM, Alexander Maassen wrote: Well, this block also affects people who have old management hardware around using such ciphers that are for example no longer supported. In my case for example the old Dell DRAC's. And it seems there is no way to disable this block. Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. Or just fallback to no SSL in some cases :( We have some old vendor things that were chugging along until everyone upgraded firefox and then suddenly they stopped working. The fix was to use the alternate non-SSL web port rather than upgrade because even though the software is old, it's too critical to upgrade it in-line. This is going to happen, probably more and more in the future. There's a point where making 99% of the web secure is better than keeping an old 1% working; so if you have hardware that's in the 1% or .1%, one day you'll wake up and there'll be an update out and that update will break your old stuff. Worse, in the future the update might have already been applied overnight. The next one of these that I know is coming, and just don't know exactly when, is RC4. Somewhere on the horizon is SHA-1. Also: 2048-bit RSA keys, 2048-bit DH, TLS 1.0. There's probably others I have forgotten.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the I'm sorry Dave sort of attitude. As an example .. we have a vendor who, in the current release (last 3 months) still requires weak ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. My $0.02 Michael Holstein Cleveland State University
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 18 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 552114 Prefixes after maximum aggregation (per Origin AS): 208717 Deaggregation factor: 2.65 Unique aggregates announced (without unneeded subnets): 269446 Total ASes present in the Internet Routing Table: 50925 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36684 Origin ASes announcing only one prefix: 16204 Transit ASes present in the Internet Routing Table:6344 Transit-only ASes present in the Internet Routing Table:173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 1393 Unregistered ASNs in the Routing Table: 468 Number of 32-bit ASNs allocated by the RIRs: 10255 Number of 32-bit ASNs visible in the Routing Table:7897 Prefixes from 32-bit ASNs in the Routing Table: 29205 Number of bogon 32-bit ASNs visible in the Routing Table:12 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:394 Number of addresses announced to Internet: 2768034912 Equivalent to 164 /8s, 252 /16s and 220 /24s Percentage of available address space announced: 74.8 Percentage of allocated address space announced: 74.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.5 Total number of prefixes smaller than registry allocations: 184582 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 136627 Total APNIC prefixes after maximum aggregation: 39587 APNIC Deaggregation factor:3.45 Prefixes being announced from the APNIC address blocks: 143533 Unique aggregates announced from the APNIC address blocks:58259 APNIC Region origin ASes present in the Internet Routing Table:5064 APNIC Prefixes per ASN: 28.34 APNIC Region origin ASes announcing only one prefix: 1193 APNIC Region transit ASes present in the Internet Routing Table:882 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1550 Number of APNIC addresses announced to Internet: 751143744 Equivalent to 44 /8s, 197 /16s and 139 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:179472 Total ARIN prefixes after maximum aggregation:87853 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182133 Unique aggregates announced from the ARIN address blocks: 85215 ARIN Region origin ASes present in the Internet Routing Table:16609 ARIN Prefixes per
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 19:54:37 -0400, Joe Maimon said: This objection hinges on the assumption that if there is even ONE host on the network that will not accept that address, then the entire effort was a waste. if there's even ONE host isn't the assertion, so do us a favor and don't claim it is. The problem is that *successfully* using the class E space for anything depends on it having pretty damned ubiquitous support. Statistics problem for you: Assuming an average hop count of 14, what percentage of intermediate routers need to support it in order to provide a 90% chance that a connection will make it through? Answer: 99.3% have to upgrade. Statistics problem 2: Assuming a 90% upgrade and 14 hops, what's the chance that a given connection works? Answer: Only 22.8%. (Yea, 0.9**14 nosedives pretty quickly). Are you starting to see the problem here? Because there would then be no difference to the many many IPv4 (and IPv6) updates that were made with no guarantee of universal adoption. The difference is that pretty much all of those other IPv4 updates were designed in such a way that failure to implement them just means failure to use *that feature*, and you could still talk unless using that feature was deemed critical to the connection. Somebody doesn't do ECN? You still talk, just without being able to use ECN. Somebody doesn't do QoS tagging? You still talk, just without being able to use QoS. Somebody doesn't do SACK? You still talk, just without being able to use SACK. Somebody doesn't do Class E? You still talk, just without being able to use Class E. Do you remember on Sesame Street, the game one of these things is not like the others? pgpSPr_G96D0t.pgp Description: PGP signature
Re: NANOG Digest, Vol 90, Issue 1
P Bob Watson On Jul 17, 2015, at 10:14 AM, Dennis B infinity...@gmail.com wrote: To Ramy, Thank you for the acknowledgement. DDoS Mitigation service providers, regardless if its pure cloud, hybrid cloud, or CPE only, all face these challenges when it comes to DDoS Attacks. Can you restate your question again or rephrase it for the forum? Seems there is some confusion or maybe people didn't grasp it. My understanding of the question RAMY asked was around DDoS mitigation providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do businesses protect themselves when attack traffic is NOT stopped at first?.IE: Defense in depth NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's. Its all moot though. These types of solutions do not guarantee up time during the initial attack start time, PERIOD! How can anyone guarantee up-time during a 40Gbps attack and lets say - all you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having larger port capacity (IE: 10GB ports) only gives you minutes/hours to react and redirect to a Cloud Provider. The time to start mitigation (average industry time) 30 - 45 minutes. What is happening to your WAN infrastructure when there is 40Gbps of attack on your doorstep. Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it will get saturated, BGP will flap and any GRE connections or any other traffic will be lost. This means, even with local CPE mitigation, things will bounce. This is 1 scenario of 1000's. There are positive security models that you can employ as as stop gap to prevent these types of scenario's, but mostly its on the Service Providers best practices or traffic posture model. IE: On-Demand, On-Demand with monitoring, Always-On monitoring, Always-On monitoring and mitigation. Having local mitigation for DDoS attacks is a loosing battle in my opinion. Its only buying you time to redirect. It does solve problems like attacks that are low in scale that you can consume with your port capacity or quick to hit and run attacks (1-2min durations). But then you need auto-mitigation enabled and that leads to collateral damage most of the times for legitimate traffic. Pretty sure other SP's will offer different opinion. This is my technical opinion, not representing Akamai or any other companies official position. From an engineering perspective, assume when an advisory targets your business and they have 1/2 way decent attacking nodes, expect an outage. Message that to the board but explain that you have every capability to mitigate these risks. Given the SP you go with has enough staff, resources, capacity, technology, SLA, and knowledge/experience in the attack vector hitting you. If you want to learn more, keep up the engagements with the market DDoS providers you are communicating with and ask these tough questions. If anyone sells you the perfect solution, they are LIEING to you! On a personal note, thank you for reaching out privately in email and explaining who you are talking too. Trust me when I tell you, I know the organization VERY WELL from the other competitor you are looking at and i will offer you my candid opinion of them, if you'd like. My friend runs their SOC over there, an old colleague of mine from when i was in the SOC blocking attacks. Love this topic! Dennis On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins rdobb...@arbor.net wrote: On 8 Jul 2015, at 22:26, Roland Dobbins wrote: Hardware-based GRE processing is required on both ends for anything other than trivial speeds; in general, the day of software-based Internet routers is long gone, and any organization still running software-based routers on their transit/peering edges at risk. To clarify, I'm referring to GRE processing on routers; hardware processing is pretty much a requirement on routers. Other types of devices can often handle GRE at significantly higher rates than software-based routers. --- Roland Dobbins rdobb...@arbor.net
Re: ATT wireless IPv6
FYI, My Note 4, With APN nextgenphone doesn't have IPv6 in Cocoa Florida (Central Florida region) Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Wednesday, July 15, 2015 6:38 PM To: Jake Khuon kh...@neebu.net Cc: North American Network Operators' Group nanog@nanog.org Subject: Re: ATT wireless IPv6 On Jul 15, 2015, at 6:29 PM, Jake Khuon kh...@neebu.net wrote: On 15/07/15 04:54, Jared Mauch wrote: Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an address out of the 2600:380:46ae::/38 space which is allocated to ATT Mobility. I exchanged a few emails earlier today with someone and it seems to depend on your APN. If you have the VoLTE APN on your device you can get IPv6, including when tethering. The APN you want is nxtgenphone. If you have a device where you can not edit the APN settings (iPhone) you can not use the IPv6 enabled VoLTE APN. I suspect this will be enabled if they launch VoLTE on the iPhone. - Jared
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
(Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 - strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the I'm sorry Dave sort of attitude. As an example .. we have a vendor who, in the current release (last 3 months) still requires weak ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. My $0.02 Michael Holstein Cleveland State University
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On Fri, Jul 17, 2015 at 07:14:17PM +, Michael O Holstein wrote: making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the I'm sorry Dave sort of attitude. First they came for SSLv2, and I said nothing because... As an example .. we have a vendor who, in the current release (last 3 months) still requires weak ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. So get up your vendors to update their stuff, and *preferably* before a super-critical hole is found in protocols that should have ideally died a natural death years ago. TLS 1.2, AES, and SHA-256 aren't exactly OMFG new! at this stage of the game. Also, take this as a learning experience: next time, make sure RFPs and contracts include an undertaking to maintain compatibility with reasonably recent standards, and financial penalties for the vendor if their failure to do so results in operational problems for you. - Matt -- aren't they getting rarer than amigas now? just without all that fuzzy good times nostalgia? -- Ron Lee, in #debian-devel, on Itanic
Re: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Weak ciphers? Old (insecure) protocol versions? Open security issues? Vendor will never provide a patch? Trash goes in the trash bin, no exceptions.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
On Fri, Jul 17, 2015 at 10:26:22AM +0200, Alexander Maassen wrote: Ok, it is good to think about security, but not giving you any chance to make exceptions is simply forcing users to use another browser in order to manage those devices, or to keep an old machine around that not gets updated. Hey, if those DRACs can't get updated to not use piss-weak ciphers, what's the problem with having one more machine laying around unpatched to manage them? - Matt
Re: another tilt at the Verizon FIOS IPv6 windmill
On Fri, 17 Jul 2015 06:25:26 -0400, Christopher Morrow morrowc.li...@gmail.com wrote: mean that your UBee has to do dhcpv6? (or the downstream thingy from the UBee has to do dhcpv6?) The Ubee router is in bridge mode. Customers have ZERO access to the thing, even when it is running in routed mode. So I have no idea what it's trying to do. All I can say is no RAs are coming from it (through it/whatever) It *could* be it's blocking it -- it's multicast, so who knows what it's doing with it. Without RAs, nothing connected to it will even attempt IPv6 -- the RA being the indicator to use DHCP or not, and who's the router. And further, when I tell my Cisco 1841 to do DHCP anyway, I get no answer. So, the blanket statement that it's ready isn't true.
BGP Update Report
BGP Update Report Interval: 09-Jul-15 -to- 16-Jul-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9829 216684 5.0% 170.9 -- BSNL-NIB National Internet Backbone,IN 2 - AS21669 126329 2.9% 126329.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 3 - AS22059 113750 2.6% 56875.0 -- -Reserved AS-,ZZ 4 - AS11056 112931 2.6% 112931.0 -- BERGERMONTAGUE - Berger Montague, P.C,US 5 - AS36947 84263 1.9% 877.7 -- ALGTEL-AS,DZ 6 - AS54169 83988 1.9% 83988.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS39891 70210 1.6% 53.1 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 8 - AS25438 65707 1.5% 619.9 -- ASN-ICCNET International Computer Company, Ltd.,SA 9 - AS370959533 1.4%2204.9 -- NET-CITY-SA - City of San Antonio,US 10 - AS33659 47554 1.1% 23777.0 -- CMCS - Comcast Cable Communications, Inc.,US 11 - AS331643148 1.0%1269.1 -- RELARN Association of scientific and educational organizations-computer networks users RELARN,RU 12 - AS24699 40378 0.9%1009.5 -- IVTELECOM-AS OJSC Rostelecom,RU 13 - AS33287 36114 0.8% 18057.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 14 - AS25563 34671 0.8% 11557.0 -- WEBLAND-AS Webland AG,CH 15 - AS10620 33665 0.8% 15.1 -- Telmex Colombia S.A.,CO 16 - AS28573 32854 0.8% 22.5 -- NET Serviços de Comunicação S.A.,BR 17 - AS131090 29996 0.7% 340.9 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 18 - AS59943 28031 0.6% 28031.0 -- RADAR-AS Radar LLC,RU 19 - AS45271 27464 0.6% 58.9 -- ICLNET-AS-AP Idea Cellular Limited,IN 20 - AS13036 24797 0.6%1549.8 -- TMOBILE-CZ T-Mobile Czech Republic a.s.,CZ TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS21669 126329 2.9% 126329.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - AS11056 112931 2.6% 112931.0 -- BERGERMONTAGUE - Berger Montague, P.C,US 3 - AS54169 83988 1.9% 83988.0 -- MGH-ION-1 - Marin General Hospital,US 4 - AS22059 113750 2.6% 56875.0 -- -Reserved AS-,ZZ 5 - AS59943 28031 0.6% 28031.0 -- RADAR-AS Radar LLC,RU 6 - AS33659 47554 1.1% 23777.0 -- CMCS - Comcast Cable Communications, Inc.,US 7 - AS33287 36114 0.8% 18057.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 8 - AS25563 34671 0.8% 11557.0 -- WEBLAND-AS Webland AG,CH 9 - AS40637 11492 0.3% 11492.0 -- MAILROUTE - MailRoute, Inc.,US 10 - AS14244 11345 0.3% 11345.0 -- NSIHOSTING-EQX-VA - NSI Hosting,US 11 - AS197914 10370 0.2% 10370.0 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - AS3935889590 0.2%9590.0 -- MUBEA-FLO - Mubea,US 13 - AS404938153 0.2%8153.0 -- FACILITYSOURCEINC - FacilitySource,US 14 - AS380006270 0.1%6270.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 15 - AS6629 7801 0.2%3900.5 -- NOAA-AS - NOAA,US 16 - AS47680 10662 0.2%3554.0 -- NHCS EOBO Limited,IE 17 - AS2015583398 0.1%3398.0 -- TFEB-AS The State Bank for Foreign Affairs of Turkmenistan,TM 18 - AS557412714 0.1%2714.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 19 - AS33440 10471 0.2%2617.8 -- WEBRULON-NETWORK - webRulon, LLC,US 20 - AS45606 11410 0.3%2282.0 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.212.8.0/24 126329 2.8% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 2 - 50.202.59.0/24 112931 2.5% AS11056 -- BERGERMONTAGUE - Berger Montague, P.C,US 3 - 204.80.242.0/24 83988 1.9% AS54169 -- MGH-ION-1 - Marin General Hospital,US 4 - 199.204.107.0/24 83657 1.9% AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 5 - 105.96.0.0/22 83525 1.9% AS36947 -- ALGTEL-AS,DZ 6 - 76.191.107.0/24 56941 1.3% AS22059 -- -Reserved AS-,ZZ 7 - 64.34.125.0/2456809 1.3% AS22059 -- -Reserved AS-,ZZ 8 - 61.7.155.0/24 29580 0.7% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 9 - 185.65.148.0/24 28031 0.6% AS59943 -- RADAR-AS Radar LLC,RU 10 - 186.208.186.0/24 14937 0.3% AS262741 -- CONECTSUL - COMERCIO E SERVICOS LTDA,BR 11 - 64.5.116.0/24 12783 0.3% AS26972 -- SIRIUS-FIBER - Sirius Fiber, Inc.,US 12 - 92.43.216.0/2111794 0.3% AS25563 -- WEBLAND-AS Webland AG,CH 13 - 199.89.0.0/21
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
* michael.holst...@csuohio.edu (Michael O Holstein) [Fri 17 Jul 2015, 21:14 CEST]: making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the I'm sorry Dave sort of attitude. Why do you upgrade your management systems asynchronously to your applications? You bring this on yourself. As an example .. we have a vendor who, in the current release (last 3 months) still requires weak ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. Why do you access mission-critical systems that are provably insecure from systems that also have internet access? If it's not mission-critical, then you should explain why you haven't dumped that vendor yet for shipping insecure software - an insecurity that is very easy to mitigate by them, should they have chosen to. -- Niels.
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Why do you upgrade your management systems asynchronously to your applications? You bring this on yourself. Perhaps, but SaaS management systems are out of our control. They TELL us when they upgrade, they do not ASK. A web browser isn't really an application, you can't wait to upgrade. Related head-shaker .. the premier vendor of time management (who shall remain nameless) requires an outdated version of java that has a number of known vulnerabilities. They have been doing this for several years now. Why do you access mission-critical systems that are provably insecure from systems that also have internet access? Because they are hosted magical unicorn cloud services .. they ARE ON the Internet. If it's not mission-critical, then you should explain why you haven't dumped that vendor yet for shipping insecure software - an insecurity that is very easy to mitigate by them, should they have chosen to. Contracts, that's why. And it's not shipping anything .. these are enterprise cloud services that cost on the order of $50k-$100k per year. My $0.02 .. any reference to a company fictional or not is purely coincidental, etc. Michael Holstein Cleveland State University
Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers
Yes, the config option in FF is global .. I'm sure it could be done with an extension though. The 'el cheapo' solution that comes to mind is use a Rasberry Pi with dual ethernet (second via USB) and run Nginx on it .. secure out the front, insecure out the back. It'd cost you something like $50. I'm surprised SSL stupidifiers aren't on sale for $9 at Aliexpress or DX. -Mike From: NANOG nanog-boun...@nanog.org on behalf of Alexander Maassen outsi...@scarynet.org Sent: Friday, July 17, 2015 4:50 PM To: nanog@nanog.org Subject: Re: SEC webpages inaccessible due to Firefox blocking servers with weak DH ciphers (Sorry Michael for the duplicate, forgot to press reply all :P) No problem making the web more secure, but in such cases I think it would have been better if you could set this behaviour per site, same as with 'invalid/self signed certs'. And in some cases, vendors use weak ciphers because they also utilize less resources. Everyone who has a DRAC knows about it's sluggish performance. Another backdraw of the DRAC's is, they are https only, and you cannot turn this behaviour off. Guess for that the only options would be to make your own interface and utilize the telnet/snmp interface. (Which is probably less secure then SSLv3), or some form of SSLv3 - strong cipher proxy. And needing to replace hardware that works perfectly fine for the purposes it's intended for just because a browser refuses to connect to it and denies you the option to make exceptions sounds just like the well known error 'Not enough money spend on hardware' On Fri, July 17, 2015 9:14 pm, Michael O Holstein wrote: making 99% of the web secure is better than keeping an old 1% working A fine idea, unless for $reason your application is among the 1% .. nevermind the arrogance of the I'm sorry Dave sort of attitude. As an example .. we have a vendor who, in the current release (last 3 months) still requires weak ciphers in authentication responses. That was mostly okay until another vendor (with more sense) wanted to auth the same way but only permitted strong ciphers. My $0.02 Michael Holstein Cleveland State University
The Cidr Report
This report has been generated at Fri Jul 17 21:14:51 2015 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
10-07-15560303 305915
11-07-15560446 305557
12-07-15559883 305833
13-07-15560432 305824
14-07-15560613 305838
15-07-15560683 306360
16-07-15561105 305878
17-07-15560782 306017
AS Summary
51217 Number of ASes in routing system
20355 Number of ASes announcing only one prefix
3294 Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
120761600 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').
--- 17Jul15 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 561291 305997 25529445.5% All ASes
AS22773 3177 166 301194.8% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS6389 2758 71 268797.4% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2699 78 262197.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS9394 2919 314 260589.2% CTTNET China TieTong
Telecommunications
Corporation,CN
AS39891 2473 33 244098.7% ALJAWWALSTC-AS Saudi Telecom
Company JSC,SA
AS28573 2286 117 216994.9% NET Serviços de Comunicação
S.A.,BR
AS3356 2584 778 180669.9% LEVEL3 - Level 3
Communications, Inc.,US
AS4766 2949 1234 171558.2% KIXS-AS-KR Korea Telecom,KR
AS10620 3294 1599 169551.5% Telmex Colombia S.A.,CO
AS9808 1586 66 152095.8% CMNET-GD Guangdong Mobile
Communication Co.Ltd.,CN
AS7545 2686 1179 150756.1% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS6983 1750 247 150385.9% ITCDELTA - Earthlink, Inc.,US
AS20115 1868 421 144777.5% CHARTER-NET-HKY-NC - Charter
Communications,US
AS4755 2034 652 138267.9% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS9498 1360 121 123991.1% BBIL-AP BHARTI Airtel Ltd.,IN
AS4323 1615 416 119974.2% TWTC - tw telecom holdings,
inc.,US
AS18566 2064 912 115255.8% MEGAPATH5-US - MegaPath
Corporation,US
AS6147 1398 277 112180.2% Telefonica del Peru S.A.A.,PE
AS7552 1158 60 109894.8% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1382 313 106977.4% CENTURYLINK-LEGACY-LIGHTCORE -
CenturyTel Internet Holdings,
Inc.,US
AS7303 1630 580 105064.4% Telecom Argentina S.A.,AR
AS4808 1513 509 100466.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network,CN
AS6849 1206 216 99082.1% UKRTELNET JSC UKRTELECOM,UA
AS8151 1702 733 96956.9% Uninet S.A. de C.V.,MX
AS26615 1098 134 96487.8% Tim Celular S.A.,BR
AS8402 984 21 96397.9% CORBINA-AS OJSC Vimpelcom,RU
AS4788 1168 248 92078.8% TMNET-AS-AP TM Net, Internet
Service Provider,MY
AS7738 999 83 91691.7% Telemar Norte Leste S.A.,BR
AS4538 2102 1253 84940.4% ERX-CERNET-BKB China Education
and Research Network
Center,CN
AS38285 977
