Gmail and SSL
I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will offer[s] a higher level of security to better protect your information. I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=enanswer=21291ctx=gmail#strictSSL
Re: Gmail and SSL
On Fri, 14 Dec 2012 09:47:03 -0600 Randy na...@afxr.net wrote: I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will offer[s] a higher level of security to better protect your information. I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. http://www.startssl.com/ Their certs are free and, from what I hear, are accepted by Google. -- John
Re: Gmail and SSL
On 12/14/2012 10:47 AM, Randy wrote: I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete
Re: Gmail and SSL
http://www.startssl.com/ Their certs are free and, from what I hear, are accepted by Google. Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. Regards, Tim.
Re: Gmail and SSL
On Fri, Dec 14, 2012 at 10:52 AM, Peter Kristolaitis alte...@alter3d.ca wrote: On 12/14/2012 10:47 AM, Randy wrote: I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. This doesn't solve the problem if you have your own internal PKI or want to use a certificate that is valid for more than a year. StartSSL is a good option, but not everyone will be able to switch for a variety of reasons. Google should provide a way of uploading trusted root CAs (including self-signed certs) if they want to perform strict validation. - Max
Re: Gmail and SSL
On Fri, Dec 14, 2012 at 11:21 AM, Tim Franklin t...@pelican.org wrote: http://www.startssl.com/ Their certs are free and, from what I hear, are accepted by Google. Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. because paying for random numbers is craziness.
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. Jason, You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most networks have entered a configuration freeze (which will usually finish at the end of 2013 week one or week two), and where two of those weeks are holiday / slack periods in large parts of the world where many people won't be working. In addition, there is no further announcement notices on www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org. You are absolutely kidding, right? Can I politely ask you / UMD to please reconsider the timing and publicisation of this change because it has important operational consequences for the entire globe. If you decide reconsider this change, could you please: - change the date to give the world several months warning. - change the date something which doesn't conflict with any of the major ethnic world holidays - create notification pages on www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org - announce more widely across e.g. other global NOG mailing lists, RIR mailing lists, etc Nick
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. Cheers, Matthew -- Matthew Newton, Ph.D. m...@le.ac.uk Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, ith...@le.ac.uk
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike
Re: Gmail and SSL
On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote: Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. because paying for random numbers is craziness. Of course, the same logic applies to IP addresses ;
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
Mike, You will need to update your root.hints file on any of your forwarding DNS servers. Most OS vendors will include an update but its a good idea to manually check. On Fri, Dec 14, 2012 at 10:59 AM, Michael Thomas m...@mtcc.com wrote: Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike
Re: Gmail and SSL
On Fri, Dec 14, 2012 at 12:04 PM, Eugen Leitl eu...@leitl.org wrote: On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote: Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. because paying for random numbers is craziness. Of course, the same logic applies to IP addresses ; see odd tunderwood's presentation on using random numbers for ip addressing, without registry support for same.
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 11:59 AM, Michael Thomas m...@mtcc.com wrote: Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? your crontab that updates your root-hints may already have caught the change... Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? ;; ANSWER SECTION: d.root-servers.net. 604800 IN A 128.8.10.90 128.8.0.0/16 - legacy space... Mike
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
If I had to guess, I would guess that renumbering is likely required to get it into a more portable address assignment from a multi-homing perspective. Look at the whois information below If I were hosting a root server or something similar, I would certainly want it segregated enough that I could manage multi-homing for that address prefix outside of my other networks. In this case, I'd assume UMDNET-1 may have monetary or administrative policies regarding the ability to be multi-homed and the degree to which it can be, however providing multiple links to UMD-ROOTD-NET is likely much easier because those decisions (or cost of connections) don't necessarily need to affect UMDNET-1 NetRange: 128.8.0.0 - 128.8.255.255 CIDR: 128.8.0.0/16 OriginAS: AS27 NetName:UMDNET-1 NetHandle: NET-128-8-0-0-1 Parent: NET-128-0-0-0-0 NetType:Direct Assignment RegDate:1984-08-01 Updated:2011-05-03 Ref:http://whois.arin.net/rest/net/NET-128-8-0-0-1 NetRange: 199.7.91.0 - 199.7.91.255 CIDR: 199.7.91.0/24 OriginAS: AS6059, AS27, AS10886 NetName:UMD-ROOTD-NET NetHandle: NET-199-7-91-0-1 Parent: NET-199-0-0-0-0 NetType:Direct Assignment RegDate:2007-12-07 Updated:2012-03-20 Ref:http://whois.arin.net/rest/net/NET-199-7-91-0-1 - Original Message - From: Michael Thomas m...@mtcc.com To: Matthew Newton m...@leicester.ac.uk Cc: nanog@nanog.org Sent: Friday, December 14, 2012 8:59:19 AM Subject: Re: Advisory — D-root is changing its IPv4 address on the 3rd of January. Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 08:59:19AM -0800, Michael Thomas wrote: Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike you might want to pick up the new belt/suspenders file aka root.hints, named.ca, et.al. and install it on your servers in the course of the next two years. if you can't reach D, then you should be able to reach the other 12. i beleive that D has not changed its IP address since before the RIR system came into existance and therefore had no idea what PI space means. Some of this stuff is really old/stable and making changes to foundational/stable systems is fraught with peril. Being careful is just being prudent. Perhaps of real interest to the NANOG community is the ability to see this prefix in their routing tables. /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Dec 14, 2012, at 8:59 AM, Michael Thomas m...@mtcc.com wrote: Matthew Newton wrote: So really stupid question, and hopefully it's just me, do I need to do something on my servers? Update the hints file. /var/named/ somewhere in all likelihood. Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Starters was a _long_ time ago, and the person who did it shouldn't be disturbed. -Bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
Hi Michael, On 2012-12-14, at 11:59, Michael Thomas m...@mtcc.com wrote: Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? When nameservers first boot, all they have is a hints file. This is either baked in to the software, or provided as a hints file, or some combination. The hints file you have today will have the current/outgoing D-Root address. The first thing a resolver does before it is ready for service, again, armed only with the hints file, is to send a priming query to a root server. This query is of the form . IN NS?. Resolvers will try servers from the hints file until they get a response. Once the priming response is received, the data originally harvested from the hints file can be thrown away. Once D-Root renumbers, a freshly booted resolver with an old hints file will either: - send a priming query to one of A, B, C, E, F, G, H, I, J, K, L, M, and obtain a response that contains the new D-Root address - send a priming query to the old D-Root v4 address, and also obtain a response that contains the new D-Root address Once service is discontinued on the current/outgoing D-Root address, such a resolver might fail to obtain a response to its priming query if it happens to try the D/v4 address first. It will re-try with a different address until it succeeds. In principle, you only need one reachable address in the hints file to work to get up and running. In summary, theory (and practice) tells us that: 1. You should update your hints file from time to time, and 2. If you don't, chances are overwhelmingly good that it will make no difference, and everything will work as normal. Joe
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 14/12/2012 16:52, Matthew Newton wrote: The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. I'm suggesting a lot more notification than 6 months before 128.8.10.90 is switched off. And corroborative announcements backed up from authoritative sources, not just a single email to nanog. It turns out that the Internet extends far beyond the borders of continental north america, and this change affects everyone who runs a resolver server. It would be really good to have a formal public statement of intent from UMD about their long term plans for 128.8.10.90 after retirement so that we don't have a repeat of the L root hijacking debacle in 2008. Everyone is extremely appreciative of the work that UMD has done in hosting this service since 1987. However, hosting a root server is a pretty big responsibility which includes maintenance of not just the existing addresses, but also all historical addresses to ensure that people who hit them after retirement (whether now or 20 years down the line) are not served bogus data. Nick
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 2012-12-14, at 11:42, Nick Hilliard n...@foobar.org wrote: You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most networks have entered a configuration freeze (which will usually finish at the end of 2013 week one or week two), and where two of those weeks are holiday / slack periods in large parts of the world where many people won't be working. To be clear: - there is no configuration change necessary in the next 3 weeks for resolvers - there is no configuration change necessary in the next 6 months for resolvers - even after 6 months, chances are resolvers which are not reconfigured will continue to work as normal You are absolutely kidding, right? These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*. Can I politely ask you / UMD to please reconsider the timing and publicisation of this change because it has important operational consequences for the entire globe. I think the trailing clause in your message above is over-stated. In fact, there are near zero operational consequences. Joe
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 12:45:00PM -0500, Joe Abley wrote: These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*. Joe i had one, back last century, when B renumbered. the old address of B was the last working address in the bootstrap file from 1986. :) i'm fairly confident that 99.% of all the existant bootstrap files on the Internet today contain at least 9 working IP addresses for root nameservers. That said, its -very- important to ensure (at each ISP, worldwide) that you have reachability to the new prefix. (wrt notification, I'm persuaded its valid and that the notice will be sent to many more groups as the hours/days progress ... remember, its not a flash change) /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
- Original Message - From: Nick Hilliard n...@foobar.org It would be really good to have a formal public statement of intent from UMD about their long term plans for 128.8.10.90 after retirement so that we don't have a repeat of the L root hijacking debacle in 2008. Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe? In point of fact, ISTM that there *is no way* to make this completely safe; granted that it's a low percentage attack, and thus probably not useful to actual attackers, but the possibility exists that someone could hijack that block at a provider level, and provide their own replacement for that old server IP. But of course, they can do it *now*, too, so I guess it doesn't matter anymore. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: Jason, You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most networks have entered a configuration freeze (which will usually finish at the end of 2013 week one or week two), and where two of those weeks are holiday / slack periods in large parts of the world where many people won't be working. Nick, I feel compelled to point out that the new service address is available now, and the old one will be available for another six months. Feel free to wait until after the holidays to make your changes. Cheers, --msa
Re: Re: Advisory — D-root is changing its IPv4 address
So really stupid question, and hopefully it's just me, do I need to do something on my servers? your crontab that updates your root-hints may already have caught the chang= e... That seems like a spectacularly bad idea. How do you validate the new root-hints automatically? What if someone manages to send you something malicious in place of the correct one? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth j...@baylink.com wrote: Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe? In point of fact, ISTM that there *is no way* to make this completely safe; granted that it's a low percentage attack, and thus probably not useful to actual attackers, but the possibility exists that someone could hijack that block at a provider level, and provide their own replacement for that old server IP. This is an extremely good point... Where will the former addresses be going after this? I'm sure someone's thought about that though...I hope.
Re: Re: Advisory — D-root is changing its IPv4 address
hand waveydnssec/hand wavey On Dec 14, 2012 1:06 PM, Joe Greco jgr...@ns.sol.net wrote: So really stupid question, and hopefully it's just me, do I need to do something on my servers? your crontab that updates your root-hints may already have caught the chang= e... That seems like a spectacularly bad idea. How do you validate the new root-hints automatically? What if someone manages to send you something malicious in place of the correct one? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
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, LacNOG, TRNOG, 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 15 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 437576 Prefixes after maximum aggregation: 180670 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 214733 Total ASes present in the Internet Routing Table: 42833 Prefixes per ASN: 10.22 Origin-only ASes present in the Internet Routing Table: 33929 Origin ASes announcing only one prefix: 15857 Transit ASes present in the Internet Routing Table:5694 Transit-only ASes present in the Internet Routing Table:135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 31 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 1188 Unregistered ASNs in the Routing Table: 426 Number of 32-bit ASNs allocated by the RIRs: 3579 Number of 32-bit ASNs visible in the Routing Table:3210 Prefixes from 32-bit ASNs in the Routing Table:8662 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space:150 Number of addresses announced to Internet: 2619294732 Equivalent to 156 /8s, 31 /16s and 68 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.0 Total number of prefixes smaller than registry allocations: 154967 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 104923 Total APNIC prefixes after maximum aggregation: 32629 APNIC Deaggregation factor:3.22 Prefixes being announced from the APNIC address blocks: 105840 Unique aggregates announced from the APNIC address blocks:43291 APNIC Region origin ASes present in the Internet Routing Table:4800 APNIC Prefixes per ASN: 22.05 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table:796 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table:386 Number of APNIC addresses announced to Internet: 716073472 Equivalent to 42 /8s, 174 /16s and 106 /24s Percentage of available APNIC address space announced: 83.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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:156038 Total ARIN prefixes after maximum aggregation:78497 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 156749 Unique aggregates announced from the ARIN address blocks: 70462 ARIN Region origin ASes present in the Internet Routing Table:15339 ARIN Prefixes per ASN:10.22 ARIN Region origin ASes
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 2012-12-14, at 13:17, Joe Antkowiak antko...@gmail.com wrote: On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth j...@baylink.com wrote: Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe? In point of fact, ISTM that there *is no way* to make this completely safe; granted that it's a low percentage attack, and thus probably not useful to actual attackers, but the possibility exists that someone could hijack that block at a provider level, and provide their own replacement for that old server IP. This is an extremely good point... Where will the former addresses be going after this? As I understand it (but ask UMD!) - D-Root is currently numbered out of a general-purpose UMD /16 into a dedicated, specifically-assigned /24 - the UMD /16 is not going anywhere The announcement is that D-Root is being renumbered, not that UMD is renumbering its whole network. Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, from an address within 128.9.0.0/16 to an address within 192.228.79.0/24 (see http://www.root-servers.org/news/new-ip-b.html). I'm sure someone's thought about that though...I hope. Joe
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 12-12-14 12:13, Joe Abley wrote: In summary, theory (and practice) tells us that: 1. You should update your hints file from time to time, and 2. If you don't, chances are overwhelmingly good that it will make no difference, and everything will work as normal. But this is important to those who write DNS server software to ensure they embed the most up to date version of the root servers in their binaries. There are also a number of much older systems which no longer get software updates (such as VAX-VMS) so it is good practice to manually maintain the root.hints files so that over time, you don't accumulate more than a couple of disused root server IP addresses.
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
- Original Message - From: Joe Abley jab...@hopcount.ca Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe? As I understand it (but ask UMD!) - D-Root is currently numbered out of a general-purpose UMD /16 into a dedicated, specifically-assigned /24 - the UMD /16 is not going anywhere The announcement is that D-Root is being renumbered, not that UMD is renumbering its whole network. So, in short, UMD will still own the losing allocation, and be able to make relatively sure nothing else is placed at that IP (though of course they won't necessarily be able to make sure no one hijacks that entire prefix -- does Renesys have a pay-special-attention list?) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
btw, the itu imploded
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
- Original Message - From: bmann...@vacation.karoshi.com So, in short, UMD will still own the losing allocation, and be able to make relatively sure nothing else is placed at that IP (though of course they won't necessarily be able to make sure no one hijacks that entire prefix -- does Renesys have a pay-special-attention list?) But how do you know the Renesys allocations haven't been hijacked?? I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are. No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: btw, the itu imploded - NOT
not at all... the WCIT 2012 concluded without agreement. Hardly the same thing. /bill
RE: btw, the itu imploded
? Again? ;) From my Galaxy Note II, please excuse any mistakes. Original message From: Randy Bush ra...@psg.com Date: 12/14/2012 11:44 AM (GMT-08:00) To: North American Network Operators' Group nanog@nanog.org Subject: btw, the itu imploded
Re: btw, the itu imploded
On Fri, Dec 14, 2012 at 11:41:48AM -0800, Randy Bush wrote: ---end quoted text--- Yep. _Gloriously_! The US walked out, followed by bunchty others. http://www.pcworld.com/article/2020469/opponents-say-itu-treaty-threatens-internet-freedom.html -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/12 11:42, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory — D-root is changing its IPv4 address on the 3rd of January. Jason, You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most networks have entered a configuration freeze (which will usually finish at the end of 2013 week one or week two), and where two of those weeks are holiday / slack periods in large parts of the world where many people won't be working. In addition, there is no further announcement notices on www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org. You are absolutely kidding, right? Hi Nick, and Nanog, I've given 3 weeks + 6 months (at least) notice on a service change that will not be noticed by most anyone. Its a change to the HINTS file, which is only used on bootstrapping. So anyone who does not update it will connect to any of the other 12 root-servers, and receive the updated IP from then on. If you have not updated your HINTS file since 1987 you may have issues bootstrapping, but you are good from 89/09/18 on. Additionally, we will be actively monitoring usage after the 6 month period to determine when best to terminate the service on the old IP. The old address, which is in the middle of UMD's network, is going to be black-holed once the change is over. Nothing will be on that IP once we move the root off. The rest of UMD's network is staying put. This move is part of UMD's commitment to improve the service, so we can support DNS anycast. Additional notice to other listservs and on web pages is coming soon. Thanks, - -- Jason -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDLiHcACgkQA5NiLuECHn7U0wCgrNA/kNTNT65yHPG9uVgUxn9m khkAoNu/kKkcTVVsFbgd7IlIHkvrDLdD =+DnX -END PGP SIGNATURE-
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 02:46:49PM -0500, Jay Ashworth wrote: - Original Message - From: bmann...@vacation.karoshi.com So, in short, UMD will still own the losing allocation, and be able to make relatively sure nothing else is placed at that IP (though of course they won't necessarily be able to make sure no one hijacks that entire prefix -- does Renesys have a pay-special-attention list?) But how do you know the Renesys allocations haven't been hijacked?? I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are. No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-) Cheers, -- jra the smart-ass answer to the nagging question on prefix reuse is: Top Men are working on it A more reasoned (maybe) response might be: To my knowledge, there is tension between creating golden addresses and address flexablity/reuse. I'd really like to swing back toward address flexability/reuse, but there is a whole lot of inertia behind the golden address crowd. Of the six renumbering events that come to mind, four of the prefixes are sequestered. The two that are not were in net 10. I am unaware of -anyone- who still points at the old addresses in net 10 space. I think there were other renumbering events, but have not kept track of the old prefix use. /bill
Re: btw, the itu imploded
On Dec 14, 2012, at 11:51 AM, Mike A mi...@mikea.ath.cx wrote: Yep. _Gloriously_! The US walked out, followed by bunchty others. http://www.pcworld.com/article/2020469/opponents-say-itu-treaty-threatens-internet-freedom.html At current count, to the best of my incomplete knowledge, approximately 85 countries, led by China, Saudi Arabia, Vietnam, and Cuba, have backed the ITU, while approximately 55 countries, led by the OECD countries, have backed the Internet. Yes, this is a radical simplification. The main unfortunate outcome is that the ITU has managed to get Study Group 3 approved to try to figure out how to override peering agreements with government-imposed settlements. Again, a radical simplification. Happy to discuss in more detail if people like. PP23 of http://files.wcitleaks.org/public/S12-WCIT12-C-0065!!MSW-E.pdf if you want to read it for yourself. -Bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 12-12-14 15:13, Jason Castonguay wrote: I've given 3 weeks + 6 months (at least) notice on a service change that will not be noticed by most anyone. Upon hearing your announcement, I went and dig myself a new root.hints file from one of the root servers. the D root is still pointing to the old address. So I had to go in and manually edit the root.hints file myself. I blame you for all that extra work :-) Would there be any impact to having the root servers immediatly provide the new IP for the D server so that a dig ns . @a.root-servers.net. root.hints would yield the new updated file ? I realise that keeping the old IP functional for some time is important for all the static configurations. But does it matter if a dynamic list is updated real time without much advance warning ?
Re: btw, the itu imploded
See also: http://www.ipv.sx/wcit/ On Fri, Dec 14, 2012 at 2:41 PM, Randy Bush ra...@psg.com wrote:
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
Hi Jean, On Dec 14, 2012, at 9:12 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: On 12-12-14 15:13, Jason Castonguay wrote: I've given 3 weeks + 6 months (at least) notice on a service change that will not be noticed by most anyone. Upon hearing your announcement, I went and dig myself a new root.hints file from one of the root servers. the D root is still pointing to the old address. So I had to go in and manually edit the root.hints file myself. I blame you for all that extra work :-) derp derp Would there be any impact to having the root servers immediatly provide the new IP for the D server so that a dig ns . @a.root-servers.net. root.hints would yield the new updated file ? As far as I understand, after 3 January 2013 such a dig command would create a new updated file with the new IP address. Kind regards, Job
Re: btw, the itu imploded
On 14/12/2012 19:51, Mike A wrote: Yep. _Gloriously_! The US walked out, followed by bunchty others. http://www.pcworld.com/article/2020469/opponents-say-itu-treaty-threatens-internet-freedom.html The ITU didn't implode and that article gives a ridiculously misleading impression of what happened. The BBC gives a more balanced viewpoint: http://www.bbc.co.uk/news/technology-20717774 There's some stuff up on some US news channels (ABC, etc), but some of the larger players (CNN, NY Times + others) haven't actually woken up to the extent of this tech/political landgrab, and have no recent articles on the outcome or the political importance of it. What actually happened is that the ITU ignored their previous promises not to have a vote on the ITRs. When a vote was finally called because it was apparently that there was no general consensus on the articles, 77 countries voted in favour and 33 voted against, causing the treaty to start the process of becoming legally binding in those countries which voted in favour. The current positions are here: http://files.wcitleaks.org/public/S12-WCIT12-C-0066!!MSW-E.pdf http://files.wcitleaks.org/public/S12-WCIT12-C-0067!!MSW-E.pdf Many countries are formally sitting on the fence, including pretty much every country in Europe which didn't walk out - also enjoy the spat in declarations #4 (argentina) and #93 (UK). Now that this landgrab has succeeded in large chunks of the world, the ITU's position has consolidated, although not nearly to the extent that had originally been envisaged in the draft ITRs. I don't forsee this debate dying any time soon. Nick
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On 12/14/2012 03:12 PM, Jean-Francois Mezei wrote: On 12-12-14 15:13, Jason Castonguay wrote: I've given 3 weeks + 6 months (at least) notice on a service change that will not be noticed by most anyone. Upon hearing your announcement, I went and dig myself a new root.hints file from one of the root servers. the D root is still pointing to the old address. So I had to go in and manually edit the root.hints file myself. I blame you for all that extra work :-) Would there be any impact to having the root servers immediatly provide the new IP for the D server so that a dig ns . @a.root-servers.net. root.hints would yield the new updated file ? I realise that keeping the old IP functional for some time is important for all the static configurations. But does it matter if a dynamic list is updated real time without much advance warning ? Hi Jean-Francois, On the 3rd you should be able to dig and see the new entry, like the dynamic list you have mentioned. Thanks, -- Jason
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay casto...@umd.edu wrote: The old address, which is in the middle of UMD's network, is going to be black-holed once the change is over. Nothing will be on that IP once we move the root off. The rest of UMD's network is staying put. This move is part of UMD's commitment to improve the service, so we can support DNS anycast. Just a quick questionif the old block is going to be black-holed but kept allocated...why does it need to be changed in the first place, or why does the existing have to be disabled? (just have both addresses active/responding?) Forgive me if I'm missing something.
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 03:10:44PM -0600, Joe Antkowiak wrote: On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay casto...@umd.edu wrote: The old address, which is in the middle of UMD's network, is going to be black-holed once the change is over. Nothing will be on that IP once we move the root off. The rest of UMD's network is staying put. This move is part of UMD's commitment to improve the service, so we can support DNS anycast. Just a quick questionif the old block is going to be black-holed but kept allocated...why does it need to be changed in the first place, or why does the existing have to be disabled? (just have both addresses active/responding?) Forgive me if I'm missing something. because you would not accept a /30 cutout of the UMD /16 coming from some random IX in Singapore. (see Joe Ableys post earlier today on why legacy nodes are / have renumbered.) /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 3:25 PM, bmann...@vacation.karoshi.com wrote: because you would not accept a /30 cutout of the UMD /16 coming from some random IX in Singapore. (see Joe Ableys post earlier today on why legacy nodes are / have renumbered.) /bill Agreed on the routing (although I wouldn't ever expect to see the subnet encompassing a root server IP advertised in the wild with..anything even close to 30 bits), and understood on the minimal/non-existant operational impacts. Guess I'm just being curious.
Re: btw, the itu imploded
WCIT-12 was but one exchange. The next one is WTPF-13: The World Telecommunication/Information and Communication Technology Policy Forum (WTPF) is a high-level international event to exchange views on the key policy issues arising from today's fast changing information and communication technology (ICT) environment. WTPF 2013 will take place in Geneva, Switzerland in May 2013. Then there is Plenipotentiary in Busan, Republic of Korea from 20 October to 7 November 2014. The Plenipotentiary Conference is the key event at which ITU Member States decide on the future role of the organization, thereby determining the organization's ability to influence and affect the development of Information and Communication Technologies (ICTs) worldwide. The Plenipotentiary Conference is the top policy-making body of the ITU. The ITU is not going away that soon. The game goes on. Gordon
RE: Gmail and SSL
A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software. matthew black california state university, long beach -Original Message- From: Peter Kristolaitis [mailto:alte...@alter3d.ca] Sent: Friday, December 14, 2012 7:53 AM To: nanog@nanog.org Subject: Re: Gmail and SSL On 12/14/2012 10:47 AM, Randy wrote: I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete
The Cidr Report
This report has been generated at Fri Dec 14 21:13:09 2012 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 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
07-12-12438154 251164
08-12-12438993 251474
09-12-12438633 251424
10-12-12438626 251518
11-12-12439046 251249
12-12-12438968 251564
13-12-12439358 252020
14-12-12440081 251852
AS Summary
42957 Number of ASes in routing system
17873 Number of ASes announcing only one prefix
3192 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
115225824 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
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').
--- 14Dec12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 439914 251807 18810742.8% All ASes
AS6389 3128 143 298595.4% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS28573 2232 70 216296.9% NET Servicos de Comunicao S.A.
AS4766 2933 923 201068.5% KIXS-AS-KR Korea Telecom
AS17974 2431 570 186176.6% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS22773 1944 137 180793.0% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS7029 3192 1457 173554.4% WINDSTREAM - Windstream
Communications Inc
AS18566 2082 423 165979.7% COVAD - Covad Communications
Co.
AS10620 2264 652 161271.2% Telmex Colombia S.A.
AS2118 1424 51 137396.4% RELCOM-AS OOO NPO Relcom
AS7303 1673 396 127776.3% Telecom Argentina S.A.
AS4323 1596 401 119574.9% TWTC - tw telecom holdings,
inc.
AS4755 1653 526 112768.2% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7552 1144 196 94882.9% VIETEL-AS-AP Vietel
Corporation
AS8151 1607 692 91556.9% Uninet S.A. de C.V.
AS7545 1820 944 87648.1% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS18101 1017 170 84783.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1128 351 77768.9% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS1785 1937 1162 77540.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS13977 856 118 73886.2% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS9808 739 29 71096.1% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS855716 53 66392.6% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS24560 1035 407 62860.7% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17676 710 90 62087.3% GIGAINFRA Softbank BB Corp.
AS3356 1115 499 61655.2% LEVEL3 Level 3 Communications
AS3549 1057 441 61658.3% GBLX Global Crossing Ltd.
AS22561 1038 439 59957.7% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS19262 1000 405 59559.5% VZGNI-TRANSIT - Verizon Online
LLC
AS18881 608 41 56793.3% Global Village Telecom
AS36998 772 213 55972.4% SDN-MOBITEL
AS22047 579 22 55796.2% VTR BANDA ANCHA S.A.
Total 45430120213340973.5% Top 30 total
BGP Update Report
BGP Update Report Interval: 06-Dec-12 -to- 13-Dec-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS982953057 2.1% 38.9 -- BSNL-NIB National Internet Backbone 2 - AS840246615 1.9% 22.9 -- CORBINA-AS OJSC Vimpelcom 3 - AS390938398 1.6%1129.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS29256 27247 1.1% 412.8 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 5 - AS730324350 1.0% 4.7 -- Telecom Argentina S.A. 6 - AS12768 23507 0.9% 242.3 -- ER-TELECOM-AS CJSC ER-Telecom Holding 7 - AS702919577 0.8% 6.6 -- WINDSTREAM - Windstream Communications Inc 8 - AS13188 18179 0.7% 31.2 -- BANKINFORM-AS TOV Bank-Inform 9 - AS28573 17709 0.7% 7.8 -- NET Servicos de Comunicao S.A. 10 - AS270815804 0.6% 113.7 -- Universidad de Guanajuato 11 - AS958313079 0.5% 10.6 -- SIFY-AS-IN Sify Limited 12 - AS29049 12828 0.5% 39.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS10620 12239 0.5% 5.8 -- Telmex Colombia S.A. 14 - AS453812056 0.5% 23.2 -- ERX-CERNET-BKB China Education and Research Network Center 15 - AS381612007 0.5% 18.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - AS475510703 0.4% 6.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 17 - AS17974 10580 0.4% 4.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS11664 10286 0.4% 33.9 -- Techtel LMDS Comunicaciones Interactivas S.A. 19 - AS14420 10038 0.4% 21.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 20 - AS58113 10022 0.4% 15.8 -- LIR-AS LIR DATACENTER TELECOM SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS2033 8808 0.3%8808.0 -- PANIX - Panix Network Information Center 2 - AS240578467 0.3%8467.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS331583136 0.1%3136.0 -- DATA-SERVICES-INC - Data Services Incorporated 4 - AS6174 5731 0.2%2865.5 -- SPRINTLINK8 - Sprint 5 - AS267995586 0.2%2793.0 -- DKR - DKR CAPITAL 6 - AS416741842 0.1%1842.0 -- ALVARION-AS Alvarion SRL 7 - AS146805021 0.2%1673.7 -- REALE-6 - Auction.com 8 - AS41539 0.1% 333.0 -- COMUNICALO DE MEXICO S.A. DE C.V 9 - AS390938398 1.6%1129.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - AS6629 7337 0.3% 917.1 -- NOAA-AS - NOAA 11 - AS38199 0.3% 460.0 -- CMED-AS Cmed Technology Ltd 12 - AS57918 858 0.0% 858.0 -- ACOD-AS ACOD CJSC 13 - AS409461178 0.1% 589.0 -- PROCON - Sat Track 14 - AS32529 582 0.0% 582.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 15 - AS172931957 0.1% 489.2 -- VTXC - VTX Communications 16 - AS451783847 0.1% 480.9 -- ROSHAN-AF Main Street, House No. 13 Wazir Akbar Khan 17 - AS57201 474 0.0% 474.0 -- EDF-AS Estonian Defence Forces 18 - AS305891320 0.1% 440.0 -- ACTIVEHOST-WASH-AVE - ActiveHost Corporation 19 - AS286676417 0.3% 427.8 -- Network Telecomunicações LTDA 20 - AS473 427 0.0% 427.0 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.254.0/24 12768 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 12767 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 12720 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 209.48.168.0/248808 0.3% AS2033 -- PANIX - Panix Network Information Center 5 - 202.14.255.0/248467 0.3% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 6 - 178.248.238.0/24 8151 0.3% AS3 -- CMED-AS Cmed Technology Ltd 7 - 192.58.232.0/247304 0.3% AS6629 -- NOAA-AS - NOAA 8 - 12.30.238.0/24 5584 0.2% AS26799 -- DKR - DKR CAPITAL 9 - 194.63.9.0/24 4446 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 12.139.133.0/244246 0.2% AS14680 -- REALE-6 - Auction.com 11 - 69.38.178.0/24 4187 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 12 - 206.80.78.0/24 3963 0.1% AS20340 -- APPIA-COMMUNICATIONS - ISPHONE, INC. 13 - 139.139.19.0/243691 0.1% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 14 - 12.183.21.0/24 3136 0.1% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated 15 -
Re: Gmail and SSL
I've heard this argument fairly often when I mention free/cheap certificates to colleagues, etc, but no one has ever actually pointed to a reasonable case where this is true (the 20 year old VMS system that I've never patched running OpenSSL 0.0.0.0.1-pre-alpha doesn't work doesn't count...). I tested my StartSSL certs against quite a number of clients and haven't found anything reasonably modern (say in the last 10 years) that didn't work either out of the box or by updating the root CA list from the OS vendor via the OS' standard patching mechanism In my experience, free/cheap certs not working on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience. If you have specific example that you know breaks with a specific (free/cheap cert, client) pair, I'd love to know so I can test it (if possible, i.e. I can actually get my hands on the client device/software). - Pete On 12/14/2012 4:45 PM, Matthew Black wrote: A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software. matthew black california state university, long beach -Original Message- From: Peter Kristolaitis [mailto:alte...@alter3d.ca] Sent: Friday, December 14, 2012 7:53 AM To: nanog@nanog.org Subject: Re: Gmail and SSL On 12/14/2012 10:47 AM, Randy wrote: I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete smime.p7s Description: S/MIME Cryptographic Signature
Re: Gmail and SSL
On Fri, Dec 14, 2012 at 6:03 PM, Peter Kristolaitis alte...@alter3d.ca wrote: In my experience, free/cheap certs not working on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience. and in the case of the original topic... if the gmail servers don't accept StartSSL certs, please let me know I'll see about a fix.
Re: OpenFlow, please don't start a flame war...
On 12/14/2012 11:11 PM, eric-l...@truenet.com wrote: It's been about 2 years in since I've heard about the concept, and honestly I'm about ready to jump into test environments at my house. My questions are pretty basic, what distro would you recommend for a controller, and should I start by virtualizing in VMWare or HyperV or jump into some cheap Linksys WRT routers. The more I hear about the tech from colleges, Google, BigSwitch, etc is leaning me to really start learning, so any help would appreciated. Yeah, it's the neatest thing since sliced bread, but requires layer-2 connectivity across the board. When you exhaust your mac address tables, we'll welcome you back to the real world. Jeff
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Dec 14, 2012, at 11:02 AM, Joe Abley jab...@hopcount.ca wrote: Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, Actually, it was L in 2007... :) Regards, -drc
Re: OpenFlow, please don't start a flame war...
On Dec 14, 2012 8:47 PM, Jeff Kell jeff-k...@utc.edu wrote: Yeah, it's the neatest thing since sliced bread, but requires layer-2 connectivity across the board. When you exhaust your mac address tables, we'll welcome you back to the real world. I think you are confusing vendor solutions with a protocol. For OpenFlow related learning and hands on I suggest the routeflow project. https://sites.google.com/site/routeflow/home
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote: On Dec 14, 2012, at 11:02 AM, Joe Abley jab...@hopcount.ca wrote: Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, Actually, it was L in 2007... :) Regards, -drc SOME people have very long memories. /bill
