tag:blogger.com,1999:blog-82358435390675634882024-03-28T03:34:13.656-04:00s.huque's blogAnonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.comBlogger44125tag:blogger.com,1999:blog-8235843539067563488.post-60188646826985512682014-07-30T08:50:00.000-04:002014-08-03T12:00:08.099-04:00Key Transparency for DNSSEC?<div dir="ltr" style="text-align: left;" trbidi="on">
At the recent <a href="http://www.ietf.org/meeting/90/" target="_blank">IETF</a> meeting in Toronto, there was an interesting discussion in the <a href="https://datatracker.ietf.org/wg/trans/charter/" target="_blank">trans working group</a> on DNSSEC certificate transparency, and there is a (very) preliminary IETF draft (that needs a lot more work):<br />
<br />
<a href="http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans" target="_blank">http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans</a><br />
<br />
This isn't a new topic. It has been talked about off and on for a number of years. The first time I ran across this was on the <a href="https://www.ietf.org/mailman/listinfo/therightkey" target="_blank">"The Right Key" email list</a> in 2012 when measures to detect and counter fraudulently issued PKI (X.509) certificates were being proposed. This ultimately led to the creation of the <a href="https://datatracker.ietf.org/wg/trans/charter/" target="_blank">trans working group</a>, whose main goal is to produce and standardize a transparency system for X.509 certificates, based on the mechanism described in <a href="http://tools.ietf.org/html/rfc6962" target="_blank">RFC 6962</a>.<br />
<br />
Does <a href="http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions" target="_blank">DNSSEC</a> need a similar transparency system? For X.509 certificates, the threats are well known and documented (I wrote about them a bit in an <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html" target="_blank">earlier blog article</a>) - any of the many root certificate authorities, or their intermediates, are capable of issuing a certificate for anyone on the Internet, and it is virtually impossible to know for sure if a fraudulent certificate has been issued. A central, cryptographically verifiable audit log of issued certificates might be able to address this issue (assuming that all CAs participated in it, which is by no means a certain proposition).<br />
<br />
For DNSSEC it isn't obvious that a similar mechanism is needed, and whenever this topic comes up,
there is a lot of head scratching and bewildered looks from DNS engineers
wondering what the possible threat model is. I must admit, I didn't foresee the possible attack, until it was described to me in this exchange on The Right Key list by Paul Hoffman and Ben Laurie:<br />
<br />
<a href="http://www.ietf.org/mail-archive/web/therightkey/current/msg00470.html">http://www.ietf.org/mail-archive/web/therightkey/current/msg00470.html</a><br />
<br />
If you'd like to read the entire email thread, it starts here:<br />
<br />
<a href="http://www.ietf.org/mail-archive/web/therightkey/current/msg00452.html">http://www.ietf.org/mail-archive/web/therightkey/current/msg00452.html</a><br />
<br />
In DNSSEC, the keys for a zone are vouched for by a single parent zone (by means of a signed <a href="http://tools.ietf.org/html/rfc3658" target="_blank">DS record</a> corresponding to the child's keys). A zone operator can query the parent's DS records himself to verify that the correct DS key is being returned. However, what the zone operator cannot do, is to verify that the parent domain is not selectively responding with false DS records to queries from a targeted set of other victims.<br />
<br />
To quote from that thread,<br />
<br />
<i>"For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B."</i><br />
<br />
(Note: for this attack to be useful, in addition to showing the fake DS records, newtld would have to show fake NS records and possibly glue records to redirect the victim to alternate DNS servers with the corresponding DNSKEY records)<br />
<br />
If the parent zone is doing this on wide scale, they are likely to get caught and face action. But highly targeted attacks will be very hard to detect. Are these scenarios far fetched? Most DNS top level domains are run by reputable organizations and would likely not risk engaging in such security shenanigans. However, even if we assume they are completely forthright, they are vulnerable to "compelled" attacks by government agencies. In April 2010, Chris Soghoian and Sid Stamm in a paper ("<a href="http://files.cloudprivacy.net/ssl-mitm.pdf" target="_blank">Certified Lies: Detecting and Defeating Government Interception Attacks against SSL</a>") describe such attacks against SSL/TLS certificates with evidence suggesting that they are actually in use. In light of Edward Snowden's NSA revelations, these kinds of compelled attacks (legally compelled or otherwise) are more likely than ever. DNSSEC keys and delegation signer records are just as vulnerable to them.<br />
<br />
The title of the IETF draft mentioned at the beginning of this article is "Certificate Transparency for DNSSEC", which is probably a misnomer. The data that would be most valuable to enter into a DNSSEC transparency log are not certificates, but secure entry point keys for zones (e.g. DS records and/or Key Signing Keys). So a more appropriate name might be "Key Transparency for DNSSEC". DNS zones <i>can</i> contain certificates, or hashes corresponding to certificates (e.g. TLSA, CERT, etc records), however there are many other record types that might contain cryptographic keying material (SSHFP, IPSECKEY, and proposals for others in the pipeline). And why not have an audit log for more mundane non-crypto records too, eg. name to address mappings? Individually logging all of these data types for every zone will likely prove to be an infeasible task.<br />
<br />
If we limit the scope of the transparency log to DS records, there are still some very significant technical challenges that need to be solved. One is scalability to the world wide DNS. The Certificate Transparency log is being implemented as <a href="https://datatracker.ietf.org/wg/trans/charter/" target="_blank">an append-only log with a Merkle tree</a>, and a DNSSEC log will likely follow the same approach. Quoting <a href="http://tools.ietf.org/html/rfc6962" target="_blank">RFC 6962</a>:<br />
<br />
<i>"The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large."</i><br />
<br />
Even though DNSSEC is still in a fledgeling state of deployment, we need to design a mechanism that can scale to the entire DNS system and accommodate the expected churn of zone keys (e.g. due to key rollovers etc). A single centralized log may not be able to do this, and alternative models may need to be considered (e.g. limiting the depth of zones that the log will hold; implementing a hierarchy of logs, etc).<br />
<br />
Another problem is that a rogue or compelled parent zone can not only return fake DS records, but could also answer authoritatively for names inside the child zone without any referrals to the child zone (a fake in-zone answer). This is harder to protect against, but I can think of a number of possible defenses. At the level of TLDs (top level domains) one possible protection might be to have DNS resolvers treat them as delegation-only and reject all subdomain answers that aren't referrals. Another (probably more promising) approach is for resolvers to employ a query-name minimization algorithm that only reveals the needed labels of the query name to authoritative DNS servers as they traverse the delegation hierarchy. In fact, there is active work going on in the DNS engineering community on such qname minimization schemes and other privacy enhancing extensions to the DNS.<br />
<br />
A DNSSEC transparency log, if deployed, could be useful as an audit channel to periodically detect attacks, and for forensics. Performing checks of the log inline with the DNS resolution process may not be practical because of the probably high performance penalty (with the currently proposed log structure), which means attacks could not be detected in real time.<br />
<br />
So is it really worth deploying such a system? I'm not yet sure. In the end, DNS is a hierarchical system, and there is always the possibility of being victimized by your parent zone either by error, incompetence, malice, or coercion. Even if we deploy centralized sets of transparency logs, we'd have to them think about how to prevent them from being compromised or co-erced. There are decentralized (non-hierarchical) naming systems out there, like gnunet, namecoin, etc. But they have the usual problem that they are only really used by a small group of very technically savvy users. We should probably take a more serious look at them. But I think the compelled attack is a very real threat, and it's probably worth some serious thought about how to deploy practical defenses against it in the global DNS.<br />
<br />
The IETF recently published <a href="http://tools.ietf.org/html/rfc7258" target="_blank">RFC 7258, declaring that pervasive monitoring is an attack</a> for which all IETF protocols should have technical countermeasures. It may also be time for the IETF to standardize mitigations for highly targeted attacks.<br />
<br />
Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com325tag:blogger.com,1999:blog-8235843539067563488.post-54754267799530031302014-07-18T23:15:00.000-04:002014-07-18T23:15:46.906-04:00Attending IETF90 in Toronto<div dir="ltr" style="text-align: left;" trbidi="on">
I'm attending the <a href="http://www.ietf.org/meeting/90/" target="_blank">IETF 90</a> meeting in Toronto, Canada this coming week. You can <a href="http://www.ietf.org/about/" target="_blank">read more about the IETF here</a>.<br />
<br />
On Sunday I'll be attending the <a href="http://www.icann.org/" target="_blank">ICANN</a> <a href="https://www.icann.org/resources/pages/rssac-4c-2012-02-25-en" target="_blank">RSSAC</a> (Root Server System Advisory Committee) meeting. I was recently appointed to the <a href="https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en" target="_blank">RSSAC Caucus</a>. The RSSAC advises the ICANN community and board on matters relating to the operation, administration, and integrity of the Internet's DNS Root Servers. During the week, I plan to attend IETF working group meetings in various areas (including DNS, Routing, HTTP, IPv6, and security). I hope to write a report of activities at the meeting after I return.<br />
<br />
Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com66tag:blogger.com,1999:blog-8235843539067563488.post-84304155732881769472014-05-02T10:42:00.002-04:002014-05-02T11:19:07.926-04:00HUQUE.COM has a signed delegation now<div dir="ltr" style="text-align: left;" trbidi="on">
(Off topic: I've been at Verisign Labs over a month now - I'll write a separate post describing my experiences at my new job when I have more time. But the short summary is: no regrets so far; lots of interesting technical work I'm getting involved in; it was probably time for me to move on from Penn; and I think I made the right decision).<br />
<br />
A few weeks ago, I created a set of test <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html">DNS TLSA records</a> in my personal zone (huque.com) to help out some folks participating in the <a href="http://blogs.verisigninc.com/blog/entry/introducing_getdns_a_modern_extensible">getdns-api hackathon</a>. To correctly authenticate records in the zone, folks needed to have resolvers configured to use the <a href="https://dlv.isc.org/">ISC DLV registry</a>, since I hadn't gotten around to setting up a secure delegation in the parent zone (.COM). This finally motivated me to get that done.<br />
<br />
Why didn't I do this earlier? Long story, but I've used my own domain for a lot of experiments with DNSSEC configurations over the years (going back to 2007), including testing configurations that I eventually deployed in other larger, production domains. The bigger stumbling block is that the DNS registrar I was using, <a href="http://www.networksolutions.com/">Network Solutions</a>, does not support DNSSEC (specifically it provides no way for customers to transmit DNSKEY or DS record contents to the TLDs it registers domains in).<br />
<br />
So last week, I started the process of changing to a DNSSEC capable registrar. There are a growing number of them out there, and <a href="http://www.icann.org/en/news/in-focus/dnssec/deployment" target="_blank">ICANN maintains a list of them</a>. The one I chose is <b><a href="https://www.gkg.net/">GKG.net</a></b>. <br />
<br />
This was my first time switching registrars - Network Solutions has been my registrar since 1998 when I first registered the domain. At that time Network Solutions both operated the .com DNS top level domain (among others) and registered domains within it. In 2000, Verisign (where I now work) acquired Network Solutions to get into the DNS business, and in 2003 spun it off as a registrar-only business, retaining operation of the .com registry. Unfortunately, as far as I can tell, Network Solutions has announced no plans to support DNSSEC.<br />
<br />
The whole process took about 5 days. On April 24th I logged into my network solutions account, unlocked my registration and requested an authorization code to transfer my domain registration. On the 25th I called them on the telephone to confirm the transfer intention and to expedite the delivery of the authorization code (it normally takes them 3 days), which I got shortly after. I then created an account at gkg.net, and initiated the domain transfer request with the supplied code. The charge was US $8.20, which included a 1-year registration period that extended beyond the current expiration date for my registration with Network Solutions. On the 28th, the transfer was successfully completed.<br />
<br />
I then logged into the gkg.net account and used their DNSSEC interface to add a DS record for huque.com, which appeared in the .COM zone more or less immediately.<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">huque.com. 86400 IN DS 40924 8 2 (<br /> 816524EB1C3B7D1315AE8330652DD17909C95DE0533C<br /> 1F2DC023BFFEDB1F5E9B )<br />huque.com. 86400 IN RRSIG DS 8 2 86400 (<br /> 20140509035959 20140502024959 56657 com.<br /> UkLdvaDKUcHmqAe8JQyXrxn+luWRKrkjfNzG4/xd/PXy<br /> zQr03L1ZXNzJHnVp7PZSau2UVfsfz5BmYGN5jepIScPc<br /> 57zd/CnKXTZgucT9ry7dHvkdmxr+UCGY1Zg4LQ0pDyAY<br /> 2avC9Hd2gJKBNJGWfZlGU/KHa1KvRv8fqlNWWQo= )</span><br />
<br />
Below is a screen capture of their DNSSEC interface. You need to supply the parameters from your zone's DNSSEC key: the keytag, algorithm, digest type, and the digest string.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiwwh5Mcpbumo2UhZwQDdwhy7Lqevi8yL_Z_Z1aVAseynO13xxKxPZ5IjKGdx9591Ca1jAVIaroTOAWUdH4qNhdg6YCXpGxs0UIGeJb2_NE6lZU5OlBCV_oNIcXRrgFfT8PPy-ruv4eqC8/s1600/gkg-dnssec-screenshot.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiwwh5Mcpbumo2UhZwQDdwhy7Lqevi8yL_Z_Z1aVAseynO13xxKxPZ5IjKGdx9591Ca1jAVIaroTOAWUdH4qNhdg6YCXpGxs0UIGeJb2_NE6lZU5OlBCV_oNIcXRrgFfT8PPy-ruv4eqC8/s1600/gkg-dnssec-screenshot.jpg" height="273" width="640" /></a></div>
<br />
Here's a graphical view of the current chain of trust for my zone from the <a href="http://dnsviz.net/">DNSviz tool</a>. As you can see, there are two secure entry paths into my zone, one via the just created normal delegation path through .COM, and one via the DLV Registry at dlv.isc.org. I will be removing the DLV entries shortly.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGuqcHVMAX5SQYeixlNEaCiIOir6nKBuT4tySYIRXjX81d_NcCPHzTpQXB_GtWLDPslL0j5mMImm3vXQwamLl6SPUGEU_6vA9wp2OQVcpyl9jImHGNXjOANM8ekm0qf8gAlVaGMsDS_HR3/s1600/dnsviz-huque.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGuqcHVMAX5SQYeixlNEaCiIOir6nKBuT4tySYIRXjX81d_NcCPHzTpQXB_GtWLDPslL0j5mMImm3vXQwamLl6SPUGEU_6vA9wp2OQVcpyl9jImHGNXjOANM8ekm0qf8gAlVaGMsDS_HR3/s1600/dnsviz-huque.png" /></a></div>
<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com54tag:blogger.com,1999:blog-8235843539067563488.post-31583122529374286852014-03-16T20:15:00.000-04:002014-03-16T21:48:01.379-04:00I've left Penn for a new job<div dir="ltr" style="text-align: left;" trbidi="on">
After more than 20 years of working at <a href="http://www.upenn.edu/" target="_blank">Penn</a> (University of Pennsylvania), I've decided to take a new job as Principal Research Scientist at <a href="http://www.verisigninc.com/en_AU/why-verisign/innovation-initiatives/labs/index.xhtml" target="_blank">Verisign Labs</a>, the applied research division of <a href="http://www.verisigninc.com/" target="_blank">Verisign Inc</a>. You might know that Verisign is one of the world's largest DNS infrastructure providers. It runs the .com, .net, .edu, and .gov DNS top level domains, two of the thirteen DNS root servers (A and J), and performs the critically important root zone management function. Verisign also provides managed DNS, Distributed Denial of Service (DDoS) mitigation, and several other services. (Note: Verisign's certificate services business was sold off to Symantec several years ago).<br />
<br />
I've been at Penn for so long, that I startled many of my colleagues with the news of my departure, so I'll say a few things about how this came about. I originally came to Penn in 1989 as an undergraduate. I became a full time IT staff member after I graduated - my first job was the system administrator of the new e-mail server for the School of Arts & Sciences, the largest school within Penn. I completed a Masters degree in Computer Science part-time while working. I later moved to the central IT organization, where I remained until last week, first as a Network Engineer, then as the Lead Engineer, and most recently as an Engineering Director. In addition, I've been a part time Adjunct Faculty in Penn's School of Engineering, teaching a laboratory course on Network Protocols.<br />
<br />
I was approached by <a href="http://www.verisigninc.com/en_AU/why-verisign/innovation-initiatives/labs/people/allison-mankin/index.xhtml" target="_blank">Allison Mankin</a> and Matt Larson (I've known both of them for a while) about a year ago to see if I'd be interested in considering a research scientist position at Verisign Labs. Matt has since left Verisign to work at Dyn, and Allison is now a Director at Verisign Labs. At the time, I thought this was distinctly a long shot, but over the course of many months, I thought more seriously about the possibility. I visited Verisign Labs in September 2013, did an interview with them, and also met Burt Kaliski, Verisign CTO (Burt is a noted cryptographer and was the founding scientist of RSA Labs, and the developer of the <a href="http://en.wikipedia.org/wiki/PKCS" target="_blank">PKCS standards</a>). I kept in touch with Allison since, but it took me until the beginning of this year to finally come to the conclusion that I wanted to take this opportunity, so here I am. My first day at Verisign will be tomorrow (March 17th).<br />
<br />
I've enjoyed my job and career at Penn a lot. I've been extensively involved in a very diverse range of technical projects, ranging from software development, systems engineering, and network design. Among others, I was responsible for the design and operation of much of the authentication and security infrastructure at Penn, as well as a variety of other services, like the DNS and DHCP (and many more that I don't have the time to enumerate here). I was the principal architect of IPv6 and DNSSEC deployment at Penn. I was the chief engineer of the <a href="http://www.magpi.net/" target="_blank">MAGPI gigapop</a> and through that role, was involved in R&E regional and national networking activities. Increasingly though, a lot of time is taken up by non-technical activities, and the longer I stay at Penn, the greater the possibility that I'll end up as a full time IT staff manager, which isn't the role I envision for myself. I've always seen my primary role as that of a technologist, and this job change will allow me to continue in that direction.<br />
<br />
Verisign Labs appears to have a true applied research agenda, which I find appealing. Obviously DNS and DNSSEC research is an area in which I expect to be working. But there are many other interesting areas of work: routing, IPv6, reputation systems, security protocols, future internet architectures, etc. I'm also looking forward to attending more NANOG and IETF meetings to get myself more plugged into those communities than I've been able to thus far. Verisign Labs also has frequent, productive collaborations with computer science researchers through its university collobaration program.<br />
<br />
In the process, I'm moving to the Washington DC metro area (specifically Reston, VA) where Verisign is located, another big change for me!<br />
<br />
More later ..<br />
<br />
--Shumon Huque.<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com97tag:blogger.com,1999:blog-8235843539067563488.post-68185237689451219722014-02-06T23:02:00.003-05:002014-02-09T19:07:17.679-05:00IPv6 versus IPv4 Performance<div dir="ltr" style="text-align: left;" trbidi="on">
Yesterday from a <a href="https://www.internetsociety.org/deploy360/blog/2014/02/comcasts-speedtest-now-breaks-out-ipv6-speed-vs-ipv4-speed/?utm_source=rss&utm_medium=rss&utm_campaign=comcasts-speedtest-now-breaks-out-ipv6-speed-vs-ipv4-speed" target="_blank">post at the Deploy360 website</a>, I learned of Comcast's IPv4 and IPv6 network speed testing tool:<br />
<br />
<span style="font-size: large;"><b><a href="http://speedtest.comcast.net/">http://speedtest.comcast.net/</a></b></span><br />
<br />
I did a quick test from my laptop in my office and got some very surprising results. The measured IPv6 performance was better than IPv4 by a gigantic margin. With IPv6, I got 822 Mbps download and 667Mbps download throughput. With IPv4, a mere 99Mbps upload and 18Mbps download!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8s89kcSsLJJTgFk4C6-YkEv0MGUIXt8uVqad26xJrfUqbHLVa2dtgq0muFDETqqfRYENNJk7UB6oKAlp8lCxC5jpVok4_ENRubljqZJPDaJb8PrCWj9rNa4peldCYQJcbpbm5XAynIyXP/s1600/myspeed.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8s89kcSsLJJTgFk4C6-YkEv0MGUIXt8uVqad26xJrfUqbHLVa2dtgq0muFDETqqfRYENNJk7UB6oKAlp8lCxC5jpVok4_ENRubljqZJPDaJb8PrCWj9rNa4peldCYQJcbpbm5XAynIyXP/s1600/myspeed.jpg" height="388" width="640" /></a></div>
<br />
Something seemed fishy, but I had to run off to other work, so I quickly <a href="https://twitter.com/shuque/status/431165567228071936" target="_blank">posted the result to Twitter</a>, planning to look into it later.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOlbKZ1Cy_fC04BzIB7xQVbj8b9ND5iChsAVbQLidmx445SGUhw-DNuRAxC-zqVLcIDxXX96vk-KuAwoBd1xpymYRjBXW3ea0849cll_uT5hNXO_63vU9UiuAxfo66Q-te2IDfdaLqIKUl/s1600/tweet1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOlbKZ1Cy_fC04BzIB7xQVbj8b9ND5iChsAVbQLidmx445SGUhw-DNuRAxC-zqVLcIDxXX96vk-KuAwoBd1xpymYRjBXW3ea0849cll_uT5hNXO_63vU9UiuAxfo66Q-te2IDfdaLqIKUl/s1600/tweet1.jpg" height="640" width="497" /></a></div>
<br />
This generated quite a bit discussion with numerous folks on twitter and elsewhere. My initial speculation was that we do some rate limiting of IPv4 traffic at the Penn border routers for selected areas of the campus, and perhaps this was throttling the IPv4 performance. My other suspicion was that there was something significantly different in the IPv4 and IPv6 routing paths contributing to the difference. The graphic above does show a round-trip time difference of 63ms for the IPv4 path and 32ms for the IPv6 path, which suggests this. Furthermore, if the TCP window is not scaled properly to keep the pipe filled for this path at 63ms (but was for 32ms), then that would decrease throughput also - but not enough to account by itself for the observed difference.<br />
<br />
Patrik Falstrom <a href="https://twitter.com/patrikhson/status/431310820916883456" target="_blank">suspected a DPI device or other middlebox</a> causing the problem. The only problem is that we don't have any such middleboxes (unless you consider an IP border router imposing IP address based rate limits a middlebox). In any case, I was leaning towards the rate limits as the cause myself, until I confirmed that those rate limits weren't being applied to any of the traffic from my office network. The rate limits are primarily targeted at the student residential dormitories - without them, our external links typically get overwhelmed with traffic to/from the dorms (most likely due to file sharing, a very common activity on college campuses). The border routers are configured to apply a token bucket rate policer to each individual IPv4 address within the network prefixes that cover the residential networks. Note that this rate limiting is completely application agnostic. Also note that this scheme cannot scale to IPv6 (a single IPv6 subnet has more than 18 quintillion addresses!), a problem we're ignoring for the time being :-)<br />
<br />
<h3 style="text-align: left;">
<b>Repeat of the test</b></h3>
<br />
This morning, I decided to do another test (same laptop), but more carefully, and along with a packet capture. I also explicitly turned off the wireless interface (hmmmm) to make sure that all tests were using the wired gigabit ethernet interface. This time, I got much more reasonable looking results, both address families in the neighborhood of each other: IPv4 853Mbps down, 547Mbps up, and for IPv6 827Mbps down, 730Mbps up. One other difference I notice is that the roundtrip (ping) times to the destination server are 12ms for both IPv4 and IPv6. This is substantially different from yesterday's test (63 and 32ms respectively) despite the fact that I choose the same destination server at Comcast (Washington, DC).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdd93pmAun7BLQTMlAXzONfZIyXMo8M3dnWq0WksVNxJxdd11TF4zwQ1kZ0zZyEcDOk_V6ts84hjXldPpcFqmMQj8nMeK-YWjebdgPw62sx9I-vW3E0x009C61BRUBh0KmDZBsUNn_ZfyZ/s1600/screen1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdd93pmAun7BLQTMlAXzONfZIyXMo8M3dnWq0WksVNxJxdd11TF4zwQ1kZ0zZyEcDOk_V6ts84hjXldPpcFqmMQj8nMeK-YWjebdgPw62sx9I-vW3E0x009C61BRUBh0KmDZBsUNn_ZfyZ/s1600/screen1.jpg" height="390" width="640" /></a></div>
<br />
A packet capture reveals that the destination server at Comcast for IPv4 was 68.87.73.52, and for IPv6 was 2001:558:1010:5:68:87:73:52. Are these the same endpoint? Hard to tell, but the fact that the last 4 fields of the IPv6 address spell out the IPv4 address in decimal might be a hint. The traffic streams use TCP port 5050. A traceroute to the IPv4 destination shows the outbound path takes one of Penn's commercial ISP links (Cogent) to New York and then back to Washington/VA. An IPv6 traceroute shows the outbound path goes out via our Internet2 link, the I2 commercial peering service, then Cogent (New York), Level3 (New York), and then Comcast to DC. So the IPv4 and IPv6 paths are substantially different in the forward direction. Harder to tell the path for the return traffic without the aid of some reverse traceroute tools or similar.<br />
<br />
Getting a substantial fraction of a gigabit ethernet is not suprising - that's probably the bottleneck bandwidth along the measured path. My laptop has a gigabit ethernet connection to the building network, which in turn has dual 10 Gigabit Ethernet links to a 100 Gig campus core, and then multiple 10Gig links out to commercial ISPs/Internet2 etc. Most tier-1 ISP links and peerings are typically at least 10Gig.<br />
<br />
The bandwidth-delay product on these paths is about 1,464 KB (1000Mbps * 12ms). The Comcast endpoint's receive window exceeds this, but my laptop's is slightly undersized, so I could probably do a bit of host tuning to boost the download numbers a bit more.<br />
<br />
So, what's the explanation for the strange results I got yesterday? I wish had a packet capture to investigate, but my leading suspicion is that my laptop's wireless adapter (lower bandwidth, shared medium) was used in the IPv4 test, and the wired connection for the IPv6 one. If I have time later, I'll try to reproduce the issue.<br />
<br />
--Shumon Huque<br />
<br />
<hr />
<br />
Addendum (February 9th 2014) - On closer inspection of the packet trace, the speed test appears to use multiple TCP streams in parallel, so scaling the window as high as the bw*delay product of the path isn't necessary.<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com43tag:blogger.com,1999:blog-8235843539067563488.post-11486404193515497062014-02-01T18:16:00.000-05:002014-05-19T11:15:36.585-04:00DNSSEC/DANE/TLSA Browser Add-ons<div dir="ltr" style="text-align: left;" trbidi="on">
The folks at <a href="http://www.nic.cz/" target="_blank">CZ.NIC</a> (the operators of the Czech Republic's country-code top level domain: <b>.cz</b>) have created a set of web browser add-ons to perform <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html" target="_blank">DNSSEC/DANE/TLSA validation</a>. You can read about them and download them from their website:<br />
<br />
<a href="https://www.dnssec-validator.cz/" target="_blank">https://www.dnssec-validator.cz/</a><br />
<br />
I installed the Firefox web browser plugin and did some quick tests of them on my own website. The plugin installs two new icons on the right side of the browser's location (URL) bar. The first with a key on it shows information about whether the domain name for the website has a valid DNSSEC signature associated with it. The second icon with a lock on it shows information about whether the TLS certificate of the website can be authenticated with a <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html" target="_blank">DANE TLSA record</a>. Here are screenshots with my own website ( https://www.huque.com/ ).<br />
<br />
In this first screenshot (below), I clicked on the key icon, and it reports that the 'www.huque.com' domain name has a valid DNSSEC signature.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggZgN65VnBnyDRF7CTsSQ5iDFjtXrxohOu7ltdrG7W2AO0NpjCvnha9Q7Qc7uqUyqrSjxirza5z-G2KRKcSmKNDwv57-czcMJad1NZ_uokl1hxCQ8AKe04JzIlempWCafRmwaIBIYn7sN8/s1600/vscreen.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggZgN65VnBnyDRF7CTsSQ5iDFjtXrxohOu7ltdrG7W2AO0NpjCvnha9Q7Qc7uqUyqrSjxirza5z-G2KRKcSmKNDwv57-czcMJad1NZ_uokl1hxCQ8AKe04JzIlempWCafRmwaIBIYn7sN8/s1600/vscreen.jpg" height="266" width="640" /></a></div>
<br />
In the next screenshow (below), I clicked on the lock icon, and it reports that the certificate for www.huque.com has been successfully authenticated by means of a signed TLSA record.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiv4kaQPNwwFo-Zi7wMrodp2FLvNWP70u7CD3pVa2Iy_nfwbe_xVfPaCq2KlJxNUpcdzXulenPI2-Fu6VSRkivCrqyyetgoL5uOWAZP7I0fybR7lPm4P7Hxf27TemXVaEDGpqBJGUzZZck/s1600/vscreen2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiv4kaQPNwwFo-Zi7wMrodp2FLvNWP70u7CD3pVa2Iy_nfwbe_xVfPaCq2KlJxNUpcdzXulenPI2-Fu6VSRkivCrqyyetgoL5uOWAZP7I0fybR7lPm4P7Hxf27TemXVaEDGpqBJGUzZZck/s1600/vscreen2.jpg" height="266" width="640" /></a></div>
<br />
In this case, since this is an HTTPS connection at the standard port (TCP port 443), the plugin looked for the TLSA record at the domain name "<b>_443._tcp.www.huque.com.</b>"<br />
<br />
<span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;"> <b>$ dig _443._tcp.www.huque.com. TLSA +noall +answer <br /> [...]<br /> _443._tcp.www.huque.com. 7200 IN TLSA 3 0 1 (<br /> 7EF4BD014E9A4F302FC1EE74FB2D29718C5B0F4CB23B<br /> 25B267A1D92F0410890B )<br /> _443._tcp.www.huque.com. 7200 IN RRSIG TLSA 8 5 7200 (<br /> 20140217205026 20140118205010 14703 huque.com.<br /> NsUKFsBAUD4OxrHQ72iB0Oz9mBoMEqL8wMsks56sp2yz<br /> 3ksXcqGSddooC3jZvGH/4iF6ssD3KRNQVONJqpK246nX<br /> jPhxBhM730TKEwMZRw/NRqYanRKyEMhkUy538suej0Pv<br /> rK3w8r6tdNF4gXqIM3sQlz9gPY/WOu0zxjezaIk= )</b></span></span><br />
<br />
Below is another screenshot for https://www.ietf.org/. In this case, the second icon has a cross marked on it, meaning that no TLSA record was found for this site. Apparently, the <a href="https://www.ietf.org/" target="_blank">IETF</a> is not yet eating its own dogfood. Although see this <a href="http://www.ietf.org/proceedings/87/slides/slides-87-dane-4.pdf" target="_blank">short slide deck from IETF'87</a> - there appears to be a proposal to do so.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSGvDy1KoYJaW2gLWYPH6DbmfSgtVVPMl1SsCNNdS71xZgN_RF9zKT3W-IooPJG4H7b1uAB7Zt_LUpuKE33ugiw6QjPF3vzkzyu1FO_HuMFuICrGKvoryRC7DfiGa0h1FTEgEPTOekvjBm/s1600/vscreen3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSGvDy1KoYJaW2gLWYPH6DbmfSgtVVPMl1SsCNNdS71xZgN_RF9zKT3W-IooPJG4H7b1uAB7Zt_LUpuKE33ugiw6QjPF3vzkzyu1FO_HuMFuICrGKvoryRC7DfiGa0h1FTEgEPTOekvjBm/s1600/vscreen3.jpg" height="246" width="640" /></a></div>
<br />
<br />
There are a few configuration options that can be set for the add-on. Here is a view of the settings window:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFGAt7bPLi_-NNPe-8cz24X-FyOlzI8mkeO1NKTloo47HX296idwC_go7LpExCmNTU5RIeKNm-e4dI-Sueq3AevhuL9rmLd-tUry08uYJ7JdO3buQJsTVhBIQOBfpry-g1T_INMVfERCRg/s1600/settings.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFGAt7bPLi_-NNPe-8cz24X-FyOlzI8mkeO1NKTloo47HX296idwC_go7LpExCmNTU5RIeKNm-e4dI-Sueq3AevhuL9rmLd-tUry08uYJ7JdO3buQJsTVhBIQOBfpry-g1T_INMVfERCRg/s1600/settings.jpg" height="400" width="308" /></a></div>
<br />
The plug-in appears to do its own DNS resolution (and validation) by default. But you can also choose to use DNS resolvers configured for your system, or a customer resolver such as the Google public resolver (8.8.8.8). <br />
<br />
If you need help creating a TLSA record for your website, I have a web based tool available here:<br />
<br />
<b> <a href="https://www.huque.com/bin/gen_tlsa" target="_blank">https://www.huque.com/bin/gen_tlsa</a></b><br />
<br />
One thing I should mention, in case you're looking at the configuration of my website: huque.com does not today have a secure delegation (i.e. DS record) published in its parent zone. This is because the registrar I use, <a href="http://www.networksolutions.com/" target="_blank">Network Solutions</a>, still cannot process requests to install DS records. I did quick check on their website (again) to see if anything's changed. Doesn't appear so:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4LxCnVGLyrl4Q5IJdXXpksVmPk_Mzvgeg9HNQ6uwcN9M0UqS6DXZ-xCAgoMk47VhEEJL_PUcZFgIA9Fi8t50yQcizZOsnCPPZyMAZiuJNN6-nJuFwpADXwWyKAcyPN4r90meAGVpc20pE/s1600/ns.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4LxCnVGLyrl4Q5IJdXXpksVmPk_Mzvgeg9HNQ6uwcN9M0UqS6DXZ-xCAgoMk47VhEEJL_PUcZFgIA9Fi8t50yQcizZOsnCPPZyMAZiuJNN6-nJuFwpADXwWyKAcyPN4r90meAGVpc20pE/s1600/ns.jpg" height="65" width="640" /></a></div>
<br />
Instead, I've had DLV record published in the <a href="https://dlv.isc.org/" target="_blank">ISC DLV Registry</a>. But there are several big resolver services, like Google DNS, and Comcast, that do not perform lookaside validation, so it's probably time to switch registrars. If anyone has suggestions for competent DNSSEC enabled registrars (with registrar-lock support), I'd be happy to receive them. I hope to make the switch soon.<br />
<br />
Dan York from ISOC also has <a href="http://www.internetsociety.org/deploy360/blog/2014/02/weekend-project-3/" target="_blank">an article on these addons here</a>. (I started writing this before seeing his!)<br />
<br />
--Shumon Huque<br />
<br />
<hr />
Addendum (May 2014): my domain huque.com now has a secure delegation from .COM.<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com43tag:blogger.com,1999:blog-8235843539067563488.post-62972988226868547272014-01-22T15:43:00.000-05:002014-01-22T15:43:02.394-05:00An IPv6 Success Story (Galois)<div dir="ltr" style="text-align: left;" trbidi="on">
The following article was contributed by Paul Heinlein, a systems administrator at <a href="http://corp.galois.com/" target="_blank">Galois</a>. Paul attended my full day IPv6 training course at <a href="https://www.usenix.org/conference/lisa13" target="_blank">USENIX LISA</a> and just a couple of months later sent me a report of his successful deployment of IPv6. So I asked if he'd like to contribute an article on the topic.<br />
<br />
It's great to hear of IPv6 success stories like this. (And of course, I'm glad folks are finding my courses useful). Significantly, his network is already seeing a very substantial amount of IPv6 traffic!<br />
<br />
(A note: the version of iptables in Redhat Enterprise Linux6/CentOS 6 has fixed the stateful IPv6 inspection capability. We use it successfully at Penn).<br />
<br />
You can find the slides from my <a href="http://www.huque.com/~shuque/doc/2013-11-ipv6-tutorial-huque.pdf" target="_blank">IPv6 training course on my website</a>.<br />
<br />
-Shumon Huque<br />
<br />
<hr />
<br />
<h3 style="text-align: left;">
An IPv6 Success Story</h3>
<h4 style="text-align: left;">
Paul Heinlein</h4>
<div style="text-align: left;">
<br />
Galois is a software-engineering firm located in Portland, OR that specializes in the hard problems of computing trust and assurance.<br />
<br />
One of our IT goals for 2014 is enabling IPv6 on all our current IPv4 subnets. I was pleased to see Shumon's full-day IPv6 tutorial on the LISA '13 schedule. I hoped he could fill the gaps in my limited<br />
experience with IPv6 and provide me the knowledge I'd need to configure our network hardware and applications.<br />
<br />
Full-day technical tutorials can sometimes test my patience, but Shumon's presentation moved quickly while remaining clear. I came away from the day thinking that I had enough basic knowledge to plan and implement our IPv6 rollout.<br />
<br />
Returning to Portland, I had to upgrade upgrade a couple core switches and apply to our ISP for a netblock prior to enabling it on our network, but once the hardware was in place, everything went reasonably well.<br />
<br />
Shumon's overview had done exactly what I'd hoped it would: allow me to interpret the various bits of vendor-specific and application-specific documentation and assemble a reasonable roll-out plan.<br />
<br />
Our DMZ and client networks are now fully IPv6 enabled. (Internal development networks will take a bit more time due to VPN-related complexity.)<br />
<br />
Along the way, I learned a couple things Shumon didn't explicitly cover in his presentation.<br />
<br />
First, make sure that reverse DNS pointers are in place for any mail server before enabling IPv6. gmail (among others) will reject messages from any mail server without reverse DNS pointers in place.<br />
<br />
Second, the ip6tables that ships with RHEL/CentOS 5 has a limited ability to do stateful packet inspection. The generic rule allowing packets from established or related sessions does not work:<br />
<br />
# this is broken in RHEL/CentOS 5<br />
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
(We've only got one CentOS 5 machine in our DMZ, so this issue hasn't impacted us in any major way.)<br />
<br />
Third, it was a lot of fun! Nearly all our DMZ services (NTP, DNS, Jabber, e-mail, www, ssh, host-based firewalls) needed updated configurations, so I learned a bunch. The day after I did the initial rollout, one of our engineers came into the office, turned off IPv4 on his Mac, and tested what percentage of Google result links he could follow. (He thought about 5%, though he said the queries he chose probably resulted in a higher success rate than might be normal.)<br />
<br />
Finally, I've been mildly surprised at the quantity of IPv6 packets traversing our border firewall. Over the past week, IPv6 has comprised 38% of overall inbound traffic and 11% of outbound. The numbers are similar when scoped to the past month.<br />
<br />
I'd like to express my thanks to Shumon for the talk and the LISA organizers for putting it on the schedule!<br />
<br />
-- Paul Heinlein <heinlein@galois.com></div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com59tag:blogger.com,1999:blog-8235843539067563488.post-48612822962429858402014-01-17T11:56:00.000-05:002014-01-17T12:05:56.490-05:00World IPv6 Launch Measurements<div dir="ltr" style="text-align: left;" trbidi="on">
From the <a href="http://www.internetsociety.org/" target="_blank">Internet Society</a>'s most recent (January 16th 2014) round of <a href="http://www.worldipv6launch.org/measurements/" target="_blank">IPv6 measurements</a>, here again are the top 100 lists ranked by the two measures of (1) percentage of requests that used
IPv6, and (2) total volume of IPv6 requests.<br />
<br />
My past articles on this topic:<br />
* <a href="http://blog.huque.com/2013/12/world-ipv6-launch-measurements.html" target="_blank">Measurements from December 12th 2013</a><br />
* <a href="http://blog.huque.com/2013/10/latest-world-ipv6-launch-measurements.html" target="_blank">Measurements from September 17th 2013</a><br />
* <a href="http://blog.huque.com/2012/08/a-look-at-world-ipv6-launch-traffic.html" target="_blank">Measurements from June 6th 2012</a><br />
<br />
<a href="http://www.worldipv6launch.org/no-let-up-in-ipv6-deployment-at-deutsche-telekom/" target="_blank">ISOC's blog post</a> highlights that Deutsche Telekom, a large German telecommunications carrier, (of which T-Mobile US is a subsidiary*) has been experiencing very substantial IPv6 traffic growth. They've reached a figure of 15.5% of requests composed of IPv6 (to the select set of content providers providing measurement data). In terms of total volume of IPv6 requests, they are in 6th place behind five other large ISPs (See the second ranked list below). Comcast still leads the pack, followed by AT&T, KDDI, Free, and Verizon Wireless.<br />
<br />
(*Note: T-Mobile's traffic is counted separately in the measurements from Deutsche Telekom)<br />
<br />
Interestingly, while Verizon Wireless has a substantial IPv6 deployment, <a href="http://www.verizonfios.com/" target="_blank">Verizon FIOS</a> (their fiber-optic landline network) has made no visible progress in IPv6 deployment. Although many people, myself included, have noted this lack of deployment over the years, they were just recently<a href="http://mailman.nanog.org/pipermail/nanog/2014-January/063391.html" target="_blank"> taken sharply to task by folks on the NANOG</a> (North American Network Operators Group) mailing list.<br />
<br />
Looking at the rankings by proportion of IPv6 requests from each network, there is a new entry at the top - <a href="http://www.nysernet.org/" target="_blank">NYSERNet</a> (a regional R&E network in New York State), coming in at a staggering 99.95%. On the Internet2 IPv6 working group list, I asked Bill Owens of NYSERNet if he wanted to comment. He claims that we shouldn't be too impressed because this is just the small NYSERNet office network and the backbone, with a relatively small population of clients. Regardless, I think it's a noteworthy achievement. As I've mentioned before, a number of universities and other educational organizations still show up prominently in this ranking. Two small american colleges, Gustavus Adolphus in Minnesota at 74.22% and Marist College in upstate New York at 65.77%! And Panamerican University, in Mexico City is at 66.22%.<br />
<br />
<a href="http://www.upenn.edu/" target="_blank">Penn</a> is slowly inching up at 45%. We'll have IPv6 deployed more extensively on our wireless network pretty soon, at which point I expect our numbers to go up noticeably.<br />
<br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;">World IPv6 Launch Measurements, by % IPv6 requests:<br />---------------------------------------------------<br /><br /> 1 NYSERNet 99.95%<br /> 2 SpeedPartner GmbH 95.83%<br /> 3 TOP-IX Consortium 86.99%<br /> 4 Fundacao Parque Tecnologico Itaipu - Brasil 79.92%<br /> 5 DirectVPS 78.63%<br /> 6 interscholz Internet Services GmbH & Co. KG 75.49%<br /> 7 Gustavus Adolphus College 74.22%<br /> 8 Google Fiber 71.87%<br /> 9 Universidad Panamericana 66.22%<br /> 10 Marist College 65.77%<br /> 11 University of Vermont 65.13%<br /> 12 Virginia Tech 65.11%<br /> 13 mur.at - Verein zur Frderung von Netzkwerkkunst 64.97%<br /> 14 Association tetaneutral.net 55.67%<br /> 15 Utility Line Italia srl 53.40%<br /> 16 ThaiSarn 53.23%<br /> 17 DegNet GmbH 52.84%<br /> 18 Trunk Networks Limited 52.60%<br /> 19 Ji?? ?trohalm 52.20%<br /> 20 Alhambra Eidos 52.12%<br /> 21 Louisiana State University 51.93%<br /> 22 Ponto de Presen?a da RNP na Bahia 51.30%<br /> 23 SuperInternet Access Pte Ltd 50.45%<br /> 24 University of New Hampshire 50.44%<br /> 25 Region 7 ESC 50.24%<br /> 26 PREGINET 50.20%<br /> 27 CICA/Junta de Andaluc?a 50.05%<br /> 28 Tanzania Network Information Center 50.00%<br /> 29 Karlsruhe Institute of Technology (KIT) 49.03%<br /> 30 Maxiweb Internet Provider 48.76%<br /> 31 Critical Colocation 48.23%<br /> 32 University of Pennsylvania 45.38%<br /> 33 SPAWAR 44.15%<br /> 34 AMS-IX 42.99%<br /> 35 University of Iowa 42.81%<br /> 36 Kasetsart University 41.99%<br /> 37 DreamHost 41.79%<br /> 38 University of Minnesota 40.80%<br /> 39 Rensselaer Polytechnic Institute 40.74%<br /> 40 Bulgaria NREN 40.57%<br /> 41 Verizon Wireless 40.03%<br /> 42 CZ.NIC 39.02%<br /> 43 guifi.net 37.86%<br /> 44 Hughes Network Systems 35.60%<br /> 45 Sauk Valley Community College 35.52%<br /> 46 Tulane University 34.96%<br /> 47 Free 34.28%<br /> 48 ARNES 33.73%<br /> 49 Greek Research & Technology Network 33.14%<br /> 50 Leibniz Supercomputing Centre 32.71%<br /> 51 Host Virtual, Inc 31.74%<br /> 52 Netwerkvereniging Coloclue 28.41%<br /> 53 Opera Software ASA 27.54%<br /> 54 UNESP 27.26%<br /> 55 UNINETT 27.13%<br /> 56 FCCN 26.00%<br /> 57 VOO 24.12%<br /> 58 RCS & RDS 23.80%<br /> 59 mc.net 23.37%<br /> 60 UFSCar 22.96%<br /> 61 EPT Luxembourg 22.43%<br /> 62 FranTech Solutions 22.03%<br /> 63 AAISP 21.22%<br /> 64 Comcast 20.61%<br /> 65 Chubu Telecommunications 18.90%<br /> 66 Swisscom 18.66%<br /> 67 XS4ALL 17.66%<br /> 68 UFSC - Universidade Federal de Santa Catarina - Brazil 17.50%<br /> 69 LENTEL 16.73%<br /> 70 StarHub 16.28%<br /> 71 Deutsche Telekom AG 15.50%<br /> 72 NIIF/Hungarnet 14.56%<br /> 73 LITNET 14.50%<br /> 74 Red Acad?mica de Centros de Investigaci?n y Universidades Nacionales REACCIUN 13.85%<br /> 75 Indiana University 13.68%<br /> 76 ATT 13.53%<br /> 77 SARENET 13.13%<br /> 78 DMZGlobal 12.97%<br /> 79 NetAssist 12.89%<br /> 80 Academia Sinica Network 12.14%<br /> 81 Cisco 11.95%<br /> 82 Solcon 11.46%<br /> 83 CESNET 11.04%<br /> 84 Funet 10.94%<br /> 85 PT. Wifian Solution 10.19%<br /> 86 FidoNet 10.12%<br /> 87 prgmr.com 9.89%<br /> 88 T-Mobile USA 9.58%<br /> 89 Monash University 9.28%<br /> 90 OVH 9.26%<br /> 91 KDDI 8.94%<br /> 92 Spectrum Networks 8.30%<br /> 93 AMRES - Serbian National Research and Education Network 7.84%<br /> 94 Belnet 7.65%<br /> 95 SWITCH 7.62%<br /> 96 Hurricane Electric 7.58%<br /> 97 M1 Limited 7.22%<br /> 98 RedIRIS 6.96%<br /> 99 Init7 6.93%<br /> 100 CJSC Progressive Technologies 6.71%<br /><br /><br />World IPv6 Launch Measurements, by volume of IPv6:<br />--------------------------------------------------</span></b><br />
<b><span style="font-family: "Courier New",Courier,monospace;"><br /></span></b>
<b><span style="font-family: "Courier New",Courier,monospace;"> 1 Comcast 20.61%<br /> 2 ATT 13.53%<br /> 3 KDDI 8.94%<br /> 4 Free 34.28%<br /> 5 Verizon Wireless 40.03%<br /> 6 Deutsche Telekom AG 15.50%<br /> 7 Time Warner Cable 3.88%<br /> 8 RCS & RDS 23.80%<br /> 9 Liberty Global 2.43%<br /> 10 Swisscom 18.66%<br /> 11 Telefonica del Peru 4.60%<br /> 12 Hughes Network Systems 35.60%<br /> 13 SoftBank BB 1.46%<br /> 14 Chubu Telecommunications 18.90%<br /> 15 Opera Software ASA 27.54%<br /> 16 VOO 24.12%<br /> 17 XS4ALL 17.66%<br /> 18 StarHub 16.28%<br /> 19 T-Mobile USA 9.58%<br /> 20 Google Fiber 71.87%<br /> 21 China Telecom 0.23%<br /> 22 Forthnet 2.79%<br /> 23 M1 Limited 7.22%<br /> 24 Internode 3.94%<br /> 25 EPT Luxembourg 22.43%<br /> 26 Janet 3.81%<br /> 27 its communications Inc.(iTSCOM) 2.64%<br /> 28 CESNET 11.04%<br /> 29 MediaCat Div./Community Netowork Center Inc. 6.58%<br /> 30 Kasetsart University 41.99%<br /> 31 NTT Communications 4.51%<br /> 32 Belnet 7.65%<br /> 33 ARNES 33.73%<br /> 34 Leibniz Supercomputing Centre 32.71%<br /> 35 LITNET 14.50%<br /> 36 NIIF/Hungarnet 14.56%<br /> 37 OVH 9.26%<br /> 38 Cisco 11.95%<br /> 39 BelWue 5.71%<br /> 40 FCCN 26.00%<br /> 41 UNINETT 27.13%<br /> 42 Altibox AS 0.90%<br /> 43 Monash University 9.28%<br /> 44 SWITCH 7.62%<br /> 45 TUBITAK ULAKBIM / ULAKNET 1.50%<br /> 46 Australian Academic and Research Network (AARNet) 2.00%<br /> 47 Indiana University 13.68%<br /> 48 University of Minnesota 40.80%<br /> 49 AAISP 21.22%<br /> 50 UniNet 3.36%<br /> 51 Xfone 018 0.96%<br /> 52 Ji?? ?trohalm 52.20%<br /> 53 Voxel / Internap 3.51%<br /> 54 GITN Sdn Berhad 2.69%<br /> 55 Louisiana State University 51.93%<br /> 56 University of Pennsylvania 45.38%<br /> 57 SuperCSI 1.69%<br /> 58 JARING Communications Sdn Bhd 0.38%<br /> 59 Solcon 11.46%<br /> 60 CJSC Progressive Technologies 6.71%<br /> 61 Starlink 1.88%<br /> 62 inexio KGaA 2.44%<br /> 63 Virginia Tech 65.11%<br /> 64 green.ch AG 3.26%<br /> 65 Hurricane Electric 7.58%<br /> 66 Dhiraagu 0.60%<br /> 67 Gustavus Adolphus College 74.22%<br /> 68 LENTEL 16.73%<br /> 69 DMZGlobal 12.97%<br /> 70 DegNet GmbH 52.84%<br /> 71 RedIRIS 6.96%<br /> 72 Academia Sinica Network 12.14%<br /> 73 GlobalConnect 1.44%<br /> 74 University of Iowa 42.81%<br /> 75 Funet 10.94%<br /> 76 University of Wisconsin - Madison 6.16%<br /> 77 Storm Internet 3.76%<br /> 78 AMRES - Serbian National Research and Education Network 7.84%<br /> 79 National Informatics Centre 2.32%<br /> 80 SoftLayer Technologies 0.84%<br /> 81 RENATER 4.57%<br /> 82 Karlsruhe Institute of Technology (KIT) 49.03%<br /> 83 guifi.net 37.86%<br /> 84 Init7 6.93%<br /> 85 Host Virtual, Inc 31.74%<br /> 86 Rensselaer Polytechnic Institute 40.74%<br /> 87 Choopa, LLC 0.55%<br /> 88 NetAssist 12.89%<br /> 89 Tulane University 34.96%<br /> 90 DreamHost 41.79%<br /> 91 Bulgaria NREN 40.57%<br /> 92 FranTech Solutions 22.03%<br /> 93 Greek Student Network 0.47%<br /> 94 RESTENA 5.33%<br /> 95 UNESP 27.26%<br /> 96 iway AG 4.06%<br /> 97 FX Networks 0.49%<br /> 98 Tanzania Network Information Center 50.00%<br /> 99 edpnet 1.11%<br /> 100 ADDIX Internet Services 3.05%</span></b><br />
<b><span style="font-family: "Courier New",Courier,monospace;"><br /></span></b></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com24tag:blogger.com,1999:blog-8235843539067563488.post-64092112888313645902013-12-19T20:26:00.000-05:002013-12-20T07:01:16.868-05:00World IPv6 Launch Measurements<div dir="ltr" style="text-align: left;" trbidi="on">
The <a href="http://www.internetsociety.org/" target="_blank">Internet Society</a> has <a href="http://www.worldipv6launch.org/measurements/" target="_blank">posted their latest IPv6 measurements (December 12th 2013)</a>. Read the section titled "Notes on network operator measurements" to understand how the measurements are being made and which content providers (Google, Facebook, Yahoo!, Akamai) are providing the data.<br />
<br />
I've pulled out some of the data, and put together ranked (top 100) lists of networks by two measures: (1) percentage of requests that used IPv6, and (2) total volume of IPv6 requests. As I've done a few times in the past, I'm going to continue periodically writing these entries to have a snapshots in time of IPv6 deployment progress.<br />
<br />
Many networks are posting some pretty impressive numbers for IPv6 usage. For the leading network in the %v6 category (the 1st list below), TOP-IX Consortium, an Italian Internet Exchange point has 86% of their requests to the participating content providers using IPv6! Several universities in the US R&E community are doing well too, Gustavus Adolphus College at 74%, Virginia Tech at 62%, University of New Hampshire at 51% among them. The University of Pennsylvania (my own institution) is posting a respectable 40% - we'll have IPv6 fully deployed on our wireless network in early 2014, at which time our numbers should go up substantially. There's an interesting story about why Penn hasn't had IPv6 on its wireless network for so long - I'm planning to write a separate article on that topic in the near future.<br />
<br />
In the total volume category (the 2nd list below) Comcast now leads. John Brzozowski, Comcast's chief IPv6 architect, has written a more <a href="http://corporate.comcast.com/comcast-voices/comcasts-xfinity-internet-now-the-worlds-largest-native-ipv6-deployment" target="_blank">detailed article on their leadership position in IPv6 deployment</a>. They are followed by several other ISPs: AT&T (US), KDDI (Japan), Free (France), Verizon Wireless, (US) Deutsche Telekom (Germany), RCS & RDS (Romania), Time Warner Cable (US).<br />
<br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;">World IPv6 Launch Measurements, by % IPv6 requests:<br />---------------------------------------------------<br /><br /> 1 TOP-IX Consortium 86.27%<br /> 2 Fundacao Parque Tecnologico Itaipu - Brasil 79.65%<br /> 3 DirectVPS 77.66%<br /> 4 ThaiSarn 76.62%<br /> 5 Gustavus Adolphus College 17234 74.17%<br /> 6 Google Fiber 70.22%<br /> 7 Universidad Panamericana 13679 66.84%<br /> 8 mur.at - Verein zur Frderung von Netzkwerkkunst 66.73%<br /> 9 interscholz Internet Services GmbH & Co. KG 66.20%<br /> 10 Virginia Tech 61.69%<br /> 11 Trunk Networks Limited 56.99%<br /> 12 Association tetaneutral.net 56.41%<br /> 13 DegNet GmbH 51.91%<br /> 14 Ponto de PresenC'a da RNP na Bahia 51.75%<br /> 15 Critical Colocation 51.38%<br /> 16 Jiri strohalm 51.29%<br /> 17 SPAWAR 51.12%<br /> 18 ITsjefen AS 51.08%<br /> 19 SuperInternet Access Pte Ltd 50.88%<br /> 20 University of New Hampshire 50.57%<br /> 21 AIMES Grid Services CIC 50.38%<br /> 22 Region 7 ESC 50.27%<br /> 23 PREGINET 50.24%<br /> 24 Maxiweb Internet Provider 50.20%<br /> 25 CICA/Junta de AndalucC-a 50.04%<br /> 26 DreamHost 49.41%<br /> 27 Alhambra Eidos 49.32%<br /> 28 Karlsruhe Institute of Technology (KIT) 48.85%<br /> 29 Sauk Valley Community College 46.13%<br /> 30 University of Minnesota 45.87%<br /> 31 Marist College 45.83%<br /> 32 AMS-IX 44.09%<br /> 33 University of Iowa 42.90%<br /> 34 Kasetsart University 41.31%<br /> 35 Verizon Wireless 40.40%<br /> 36 University of Pennsylvania 40.06%<br /> 37 Bulgaria NREN 38.74%<br /> 38 guifi.net 38.69%<br /> 39 Rensselaer Polytechnic Institute 37.91%<br /> 40 Louisiana State University 35.74%<br /> 41 Leibniz Supercomputing Centre 35.17%<br /> 42 Netwerkvereniging Coloclue 32.66%<br /> 43 Free 31.03%<br /> 44 UNESP 30.15%<br /> 45 NetAssist 29.72%<br /> 46 ARNES 28.98%<br /> 47 Tulane University 28.88%<br /> 48 Utility Line Italia srl 28.19%<br /> 49 Host Virtual, Inc 27.79%<br /> 50 Hughes Network Systems 27.28%<br /> 51 FCCN 26.96%<br /> 52 UFSCar 26.36%<br /> 53 VOO 25.94%<br /> 54 Opera Software ASA 25.69%<br /> 55 Greek Research & Technology Network 24.94%<br /> 56 UNINETT 24.58%<br /> 57 LENTEL 23.48%<br /> 58 Chubu Telecommunications 22.76%<br /> 59 RCS & RDS 22.01%<br /> 60 mc.net 20.20%<br /> 61 Comcast 20.15%<br /> 62 Monash University 19.82%<br /> 63 Swisscom 19.64%<br /> 64 UFSC - Universidade Federal de Santa Catarina - Brazil 19.25%<br /> 65 XS4ALL 18.52%<br /> 66 AAISP 18.13%<br /> 67 SIDN 17.11%<br /> 68 EPT Luxembourg 16.72%<br /> 69 manitu GmbH 15.88%<br /> 70 VentraIP Group (Australia) Pty Ltd 15.73%<br /> 71 LITNET 15.09%<br /> 72 Hurricane Electric 14.88%<br /> 73 ATT 14.82%<br /> 74 NIIF/Hungarnet 14.43%<br /> 75 Funet 12.60%<br /> 76 CESNET 12.33%<br /> 77 Deutsche Telekom AG 12.28%<br /> 78 Indiana University 12.14%<br /> 79 OVH 11.63%<br /> 80 FranTech Solutions 10.98%<br /> 81 Red Academica de Centros de InvestigaciC3n y Universidades Nacionales REACCIUN 10.95%<br /> 82 UniNet 10.48%<br /> 83 Host.MD 10.35%<br /> 84 Belnet 9.73%<br /> 85 Cisco 9.70%<br /> 86 CJSC Progressive Technologies 9.65%<br /> 87 KDDI 8.87%<br /> 88 Academia Sinica Network 8.22%<br /> 89 SARENET 8.01%<br /> 90 DMZGlobal 7.99%<br /> 91 SWITCH 7.86%<br /> 92 Init7 7.70%<br /> 93 MediaCat Div./Community Netowork Center Inc. 7.52%<br /> 94 AMRES - Serbian National Research and Education Network 7.10%<br /> 95 RedIRIS 6.74%<br /> 96 T-Mobile USA 6.49%<br /> 97 Voxel / Internap 6.48%<br /> 98 Defense Research and Engineering Network 6.41%<br /> 99 prgmr.com 6.35%<br /> 100 M1 Limited 6.29%<br /><br /><br />World IPv6 Launch Measurements, by volume of IPv6:<br />--------------------------------------------------<br /><br /> 1 Comcast 20.15%<br /> 2 ATT 14.82%<br /> 3 KDDI 8.87%<br /> 4 Free 31.03%<br /> 5 Verizon Wireless 40.40%<br /> 6 Deutsche Telekom AG 12.28%<br /> 7 RCS & RDS 22.01%<br /> 8 Time Warner Cable 4.07%<br /> 9 Liberty Global 2.52%<br /> 10 Telefonica del Peru 5.14%<br /> 11 Swisscom 19.64%<br /> 12 SoftBank BB 1.65%<br /> 13 Hughes Network Systems 27.28%<br /> 14 Chubu Telecommunications 22.76%<br /> 15 Opera Software ASA 25.69%<br /> 16 VOO 25.94%<br /> 17 XS4ALL 18.52%<br /> 18 China Telecom 0.18%<br /> 19 Janet 4.29%<br /> 20 T-Mobile USA 6.49%<br /> 21 Forthnet 3.35%<br /> 22 StarHub 4.81%<br /> 23 University of Minnesota 45.87%<br /> 24 Indiana University 12.14%<br /> 25 CESNET 12.33%<br /> 26 Google Fiber 70.22%<br /> 27 M1 Limited 6.29%<br /> 28 Virginia Tech 61.69%<br /> 29 Internode 4.53%<br /> 30 FCCN 26.96%<br /> 31 EPT Luxembourg 16.72%<br /> 32 Cisco 9.70%<br /> 33 Belnet 9.73%<br /> 34 Louisiana State University 35.74%<br /> 35 RedIRIS 6.74%<br /> 36 UNINETT 24.58%<br /> 37 Leibniz Supercomputing Centre 35.17%<br /> 38 its communications Inc.(iTSCOM) 3.14%<br /> 39 SWITCH 7.86%<br /> 40 NIIF/Hungarnet 14.43%<br /> 41 ARNES 28.98%<br /> 42 MediaCat Div./Community Netowork Center Inc. 7.52%<br /> 43 BelWue 5.87%<br /> 44 LITNET 15.09%<br /> 45 University of Pennsylvania 40.06%<br /> 46 NTT Communications 4.38%<br /> 47 RENATER 4.10%<br /> 48 Kasetsart University 41.31%<br /> 49 University of Iowa 42.90%<br /> 50 TUBITAK ULAKBIM / ULAKNET 1.29%<br /> 51 OVH 11.63%<br /> 52 Tulane University 28.88%<br /> 53 Monash University 19.82%<br /> 54 UNESP 53166 30.15%<br /> 55 AMRES - Serbian National Research and Education Network 7.10%<br /> 56 Rensselaer Polytechnic Institute 37.91%<br /> 57 UFSC - Universidade Federal de Santa Catarina - Brazil 19.25%<br /> 58 University of Wisconsin - Madison 4.84%<br /> 59 Gustavus Adolphus College 74.17%<br /> 60 Funet 12.60%<br /> 61 GARR 1.25%<br /> 62 Marist College 45.83%<br /> 63 SPAWAR 51.12%<br /> 64 SURFnet 1.36%<br /> 65 SuperCSI 2.71%<br /> 66 Altibox AS 0.70%<br /> 67 AAISP 18.13%<br /> 68 Australian Academic and Research Network (AARNet) 2.32%<br /> 69 Karlsruhe Institute of Technology (KIT) 48.85%<br /> 70 Xfone 018 1.11%<br /> 71 UFSCar 26.36%<br /> 72 Voxel / Internap 6.48%<br /> 73 Solcon 5.12%<br /> 74 UniNet 10.48%<br /> 75 CJSC Progressive Technologies 9.65%<br /> 76 CICA/Junta de AndalucC-a 50.04%<br /> 77 Starlink 1.47%<br /> 78 Hurricane Electric 14.88%<br /> 79 Greek Research & Technology Network 24.94%<br /> 80 Jiri strohalm 51.29%<br /> 81 JARING Communications Sdn Bhd 0.27%<br /> 82 Defense Research and Engineering Network 6.41%<br /> 83 GITN Sdn Berhad 3.11%<br /> 84 Dhiraagu 0.85%<br /> 85 Academia Sinica Network 8.22%<br /> 86 green.ch AG 2.83%<br /> 87 Louisiana Optical Network Initiative 5.04%<br /> 88 LENTEL 23.48%<br /> 89 Fundacao Parque Tecnologico Itaipu - Brasil 79.65%<br /> 90 DegNet GmbH 51.91%<br /> 91 National Informatics Centre 2.19%<br /> 92 guifi.net 38.69%<br /> 93 GlobalConnect 1.54%<br /> 94 The Tertiary Education and Research Network of South Africa (TENET) 1.53%<br /> 95 DMZGlobal 7.99%<br /> 96 Init7 7.70%<br /> 97 SoftLayer Technologies 1.40%<br /> 98 Ponto de PresenC'a da RNP na Bahia 51.75%<br /> 99 Storm Internet 5.40%<br /> 100 inexio KGaA 1.15%</span></b><br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com23tag:blogger.com,1999:blog-8235843539067563488.post-49766261373250053022013-12-01T10:30:00.001-05:002013-12-01T22:31:31.175-05:00EDU Top Level Domain statistics<div dir="ltr" style="text-align: left;" trbidi="on">
Some DNS Top Level Domain (TLD) operators publish statistics about their DNS zones. Some others have a zone file access program that allows others to examine their data and publish statistics. Frederic Cambus (@fcambus on Twitter) maintains a site called <a href="http://www.statdns.com/" target="_blank">statdns</a> ( <a href="http://www.statdns.com/">http://www.statdns.com/</a> ) that keeps statistics for several of the TLDs.<br />
<br />
The EDU top level domain is conspicuously absent from the statdns site because the operators don't publish any statistics and also don't have a zone file access program in place. The EDU domain has a very complicated operational policy arrangement. It is managed by <a href="http://www.educause.edu/" target="_blank">Educause</a> (a higher education IT consortium), but operated by <a href="http://www.verisigninc.com/" target="_blank">Verisign</a>, under a contract with the <a href="http://www.commerce.gov/" target="_blank">United States Department of Commerce</a>. I recently spoke with colleagues at Educause about current prospects for publishing some statistics or making the zone data available. The good news is that a zone file access program request is in fact in the queue to be approved by the Dept of Commerce. But it's stuck behind a few other requests, so it may still take some time to come to fruition.<br />
<br />
In the meantime, to satisfy my own curiosity, I've been looking at other ways to obtain some statistics. In particular I'm interested in seeing how much DNSSEC deployment has happened so far, and how EDU compares with some of the other TLDs in this respect. One way to gain visibility into zone contents is to examine passive DNS databases. A number of folks and organizations run such databases that collect historical information seen from DNS responses at collections of resolvers. By searching records over a period of time in these databases, it's possible to reconstruct a substantial portion of the active records in a zone. I did this for EDU and analyzed the results recently.<br />
<br />
The passive DNS database search managed to find about 7,158 second level domains under EDU. Of these, 6955 domains turned out to be valid (the others probably existed at one point but don't any more). EDU is known to have in the neighborhood of 7,000 delegations, so this is most probably a pretty good approximation of the active contents of the zone.<br />
<br />
<u><b>EDU Zone Statistics:</b></u><br />
<br />
Number of Domains from passive DNS db: 7158<br />
Number of Valid Domains: 6955<br />
<br />
Total NS records: 19527<br />
Unique NS records: 9757<br />
Number of (glue) IPv4 address records: 4555<br />
Number of (glue) IPv6 address records: 246<br />
<br />
<u><b>DNSSEC Specific Stats for EDU:</b></u><br />
<br />
Number of DNSSEC Signed Zones: 94 (1.37%)<br />
Number of NSEC3 Zones: 29 (30.1% of the signed zones)<br />
Number of Zones with DS records: 76<br />
Number of Zones with DLV records at dlv.isc.org: 7 <br />
<br />
As expected, only a very small fraction (1.37%) of domains have deployed DNSSEC. This compares with about 0.25% in .COM, 0.41% in .NET, and 0.30% in .ORG.<br />
<br />
The 94 zones in EDU signed with DNSSEC are:<br />
<br />
acadiana.edu<br />
baker.edu<br />
beloit.edu<br />
berkeley.edu<br />
bucknell.edu<br />
cameron.edu<br />
carnegiemellon.edu<br />
catc.edu<br />
chattanoogastate.edu<br />
cltc.edu<br />
cmu.edu<br />
coloradomesa.edu<br />
cookman.edu<br />
csupomona.edu<br />
cuhk.edu<br />
desales.edu<br />
drake.edu<br />
example.edu<br />
fhsu.edu<br />
fhtc.edu<br />
gfcmsu.edu<br />
gsu.edu<br />
gtc.edu<br />
hfg.edu<br />
highlands.edu<br />
indiana.edu<br />
indianatech.edu<br />
internet2.edu<br />
iu.edu<br />
iub.edu<br />
iup.edu<br />
iupui.edu<br />
jhuapl.edu<br />
kestrel.edu<br />
kiropraktik.edu<br />
k-state.edu<br />
ksu.edu<br />
kutztown.edu<br />
lctcs.edu<br />
lsu.edu<br />
ltc.edu<br />
ma.edu<br />
mansfield.edu<br />
mcpherson.edu<br />
merit.edu<br />
mesa.edu<br />
millikin.edu<br />
mnsfld.edu<br />
monmouth.edu<br />
monterey.edu<br />
mst.edu<br />
nau.edu<br />
northcentral.edu<br />
northshorecollege.edu<br />
nwltc.edu<br />
okstate.edu<br />
pacificu.edu<br />
penn.edu<br />
pitt.edu<br />
psc.edu<br />
richland.edu<br />
rockefeller.edu<br />
rose-hulman.edu<br />
scl.edu<br />
sdsmt.edu<br />
sfcollege.edu<br />
shoreline.edu<br />
suu.edu<br />
tbu.edu<br />
tiasnimbas.edu<br />
tilburguniversity.edu<br />
tiss.edu<br />
truman.edu<br />
uaa.edu<br />
ualr.edu<br />
ucaid.edu<br />
ucb.edu<br />
ucberkeley.edu<br />
ucdavis.edu<br />
ucr.edu<br />
uiowa.edu<br />
umbc.edu<br />
uni-stuttgart.edu<br />
unt.edu<br />
untsystem.edu<br />
upenn.edu<br />
upf.edu<br />
usnwc.edu<br />
uwm.edu<br />
uwstout.edu<br />
valencia.edu<br />
waketech.edu<br />
washjeff.edu<br />
weber.edu<br />
<br />
The 29 zones that use the NSEC3 variety of DNSSEC are:<br />
<br />
csupomona.edu<br />
cuhk.edu<br />
gfcmsu.edu<br />
internet2.edu<br />
jhuapl.edu<br />
kestrel.edu<br />
kiropraktik.edu<br />
k-state.edu<br />
ksu.edu<br />
lsu.edu<br />
ma.edu<br />
mansfield.edu<br />
mcpherson.edu<br />
millikin.edu<br />
mnsfld.edu<br />
pitt.edu<br />
richland.edu<br />
rose-hulman.edu<br />
sdsmt.edu<br />
suu.edu<br />
tiasnimbas.edu<br />
tilburguniversity.edu<br />
ualr.edu<br />
ucaid.edu<br />
ucr.edu<br />
uni-stuttgart.edu<br />
unt.edu<br />
untsystem.edu<br />
washjeff.edu<br />
<br />
There are 18 zones that do not have DS records published (not sure why):<br />
<br />
beloit.edu<br />
cameron.edu<br />
cookman.edu<br />
iup.edu<br />
kiropraktik.edu<br />
kutztown.edu<br />
mansfield.edu<br />
merit.edu<br />
mnsfld.edu<br />
okstate.edu<br />
shoreline.edu<br />
tbu.edu<br />
tiasnimbas.edu<br />
uaa.edu<br />
usnwc.edu<br />
uwm.edu<br />
uwstout.edu<br />
waketech.edu<br />
<br />
There are also 7 zones with DLV records published at <a href="https://dlv.isc.org/" target="_blank">ISC's DLV registry</a>, but this set is disjoint with the set that doesn't have DS records:<br />
<br />
bucknell.edu<br />
internet2.edu<br />
k-state.edu<br />
ksu.edu<br />
ualr.edu<br />
ucaid.edu<br />
ucr.edu<br />
<br />
-- Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com36tag:blogger.com,1999:blog-8235843539067563488.post-40451624040850038982013-11-20T21:21:00.000-05:002013-11-21T13:29:43.035-05:00New DNS Top Level Domains<div dir="ltr" style="text-align: left;" trbidi="on">
If you follow DNS news, you may know that <a href="http://www.icann.org/" target="_blank">ICANN</a> has put in place a program to introduce many <a href="http://newgtlds.icann.org/" target="_blank">new generic top level domains (GTLD</a>) into the DNS. I haven't been a fan. ICANN says there is market demand for GTLD expansion (perhaps), and that it allows innovation in the DNS ecosystem (how?). It probably will have an effect of diluting the entrenched market power of the big TLD operators (.com, .org etc), which may be a good thing. But the system may end up being primarily a significant financial windfall for ICANN. Even Esther Dyson (original ICANN chair) has spoken out against the program.<br />
<br />
There appear to be some trademark protection mechanisms built in to the new system. But it seems clear that many organizations will rush to defensively register their names under some of the new TLDs. Strictly speaking, DNS domain names have no intended or actual relation to trademarks, but we have to deal with the real world. My university's upper administration has already contacted the IT department to discuss the topic. A while back, we defensively registered "upenn.xxx" to protect against possible reputational damage (and no, I wasn't involved in that decision).<br />
<br />
On a more technical note, one interesting and welcome feature of the new GTLDs, is that they must be deployed with DNSSEC. This should significantly increase the proportion of signed top level domains in the DNS. My <a href="http://www.huque.com/app/dnsstat/" target="_blank">dnsstat DNS monitoring site</a> has been monitoring the TLDs for a while now, and I just updated it with the <a href="http://www.huque.com/app/dnsstat/category/tld/" target="_blank">latest list of TLDs</a>.<br />
<br />
<a href="http://www.huque.com/app/dnsstat/category/tld/">http://www.huque.com/app/dnsstat/category/tld/</a><br />
<br />
Since late August, 32 new TLDs have been introduced, 27 normal GTLDs, 5 IDN (Internationalized domains) TLDs. But 11 IDN TLDs have also disappeared. That's a net gain of 21 TLDs, bringing the total count to 339.<br />
<br />
Some DNSSEC specific stats: 143 (or 42.2%) of the TLDs are signed with DNSSEC. Here's a breakdown of type key and zone signing algorithms in use for the signed TLDs:<br />
<br />
<u>Key Signing Keys (KSK):</u><br />RSASHA256 (8) = 119 (63.0%)<br />RSASHA512 (10) = 6 (3.2%)<br />RSASHA1 (5) = 16 (8.5%)<br />RSASHA1-NSEC3-SHA1 (7) = 48 (25.4%)<br /><br /><u>Zone Signing Keys (ZSK):</u><br />RSASHA256 (8) = 133 (62.4%)<br />RSASHA512 (10) = 8 (3.8%)<br />RSASHA1 (5) = 17 (8.0%)<br />RSASHA1-NSEC3-SHA1 (7) = 55 (25.8%) <br />
<br />
Note: new GTLDs continue to be added, so the numbers in this article might be out of date soon.<br />
<br />
Here are the added TLDs so far (as of November 20th 2013):<br />
<br />
+ bike<br />
+ camera<br />
+ clothing<br />
+ construction<br />
+ contractors<br />
+ diamonds<br />
+ directory<br />
+ enterprises<br />
+ equipment<br />
+ estate<br />
+ gallery<br />
+ graphics<br />
+ guru<br />
+ holdings<br />
+ kitchen<br />
+ land<br />
+ lighting<br />
+ photography<br />
+ plumbing<br />
+ sexy<br />
+ singles<br />
+ tattoo<br />
+ technology<br />
+ tips<br />
+ today<br />
+ ventures<br />
+ voyage<br />
<br />
Here are the new IDN TLDs:<br />
<br />
+ xn--80asehdb<br />
+ xn--80aswg<br />
+ xn--mgba3a4f16a<br />
+ xn--ngbc5azd<br />
+ xn--unup4y<br />
<br />
Here are the deleted IDN TLDs:<br />
<br />
- xn--0zwm56d<br />
- xn--11b5bs3a9aj6g<br />
- xn--80akhbyknj4f<br />
- xn--9t4b11yi5a<br />
- xn--deba0ad<br />
- xn--g6w251d<br />
- xn--hgbk6aj7f53bba<br />
- xn--hlcj6aya9esc7a<br />
- xn--jxalpdlp<br />
- xn--kgbechtv<br />
- xn--zckzah<br />
<br />
Note: one IDN TLD (xn--l1acc) has had a severely busted DNSSEC deployment for a while. My monitoring system detects that its DS records in the root of the DNS do not match any DNSKEY records in the zone, and furthermore, the signatures on the DNSKEY records have expired. I hope they get their act together soon.<br />
<br />
--Shumon Huque</div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com16tag:blogger.com,1999:blog-8235843539067563488.post-34248440294708073932013-11-16T14:27:00.002-05:002013-11-16T14:30:50.653-05:00Penn wins NSF Campus CyberInfrastructure Award<div dir="ltr" style="text-align: left;" trbidi="on">
A while back in a blog article on our <a href="http://blog.huque.com/2013/06/100-gigabit-ethernet-at-penn.html" target="_blank">100 Gigabit Ethernet campus upgrades</a>, I mentioned that <a href="http://www.upenn.edu/" target="_blank">Penn</a> had applied for a <a href="http://www.nsf.gov/" target="_blank">National Science Foundation</a> (NSF) <a href="http://www.nsf.gov/pubs/2013/nsf13530/nsf13530.htm" target="_blank">CC-NIE grant</a> to enhance campus network infrastructure for research purposes.<br />
<br />
We did in fact win an award. Here's the <a href="http://www.nsf.gov/awardsearch/showAward?AWD_ID=1340936&HistoricalAwards=false" target="_blank">official notice from NSF</a>. It's about $500,000 which will be used to deploy a dedicated high performance router for researchers and bump up our external connectivity to <a href="http://www.internet2.edu/" target="_blank">Internet2</a> to 100 Gbps. I hope to provide more updates as we begin deploying the necessary pieces of equipment.<br />
<br />
--Shumon Huque<br />
<br />
An excerpt from the award notice:<br />
<br />
<b class="greybold">ABSTRACT</b><br />
<br />
The University of Pennsylvania's central computing
organization is partnering with leading campus researchers in
engineering, physics, biology, pathology, genomics, bioinformatics, and
computer science to optimize the campus network in support of big data
research and high-performance computing. This project establishes a 100
Gbps-capable Science DMZ that is distinct from the general purpose
campus network and is engineered for research applications.
Additionally, it extends 10 Gbps connectivity to select research
projects and increases Penn's connection to Internet2 from 1 Gbps to 100
Gbps, while also extending that connection to the Science DMZ. The
project also lays the foundation for further enhancements to research
networking infrastructure by extending IPv6 capabilities; upgrading
network monitoring tools such as perfSONAR; and enhancing Penn's ability
to support experimental networks and network architectures, including
OpenFlow and Software Defined Networking. <br />
<br />
The project will
benefit a range of scientifically meritorious research. It will provide
support for the large-scale data transfer, processing, and storage needs
of researchers across Penn, while supporting intra- and
inter-institutional collaborations and the broad dissemination of
research results. Rather than focusing on the logistics of data storage
and transfer, researchers will be able to concentrate on the
transformation of these data into the information that will drive new
discoveries and the creation of new technologies, drugs, therapies, and
cures. Network enhancements will also support Penn's commitment to
integrating research and education by supporting the network needs of
the cross-disciplinary Penn Institute for Computation Science that where
faculty actively integrate computation-based research with the training
of future generations of STEM researchers.<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com68University of Pennsylvania, 3451 Walnut Street, Philadelphia, PA 19104, USA39.9503816 -75.19664369999998139.9260361 -75.236984199999981 39.9747271 -75.156303199999982tag:blogger.com,1999:blog-8235843539067563488.post-74461642719700269752013-10-23T21:33:00.002-04:002013-10-23T21:33:52.223-04:00TLSA Record Generator<div dir="ltr" style="text-align: left;" trbidi="on">
Last year I wrote a blog article on <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html" target="_blank">DNSSEC and Certificates</a>. Occasionally I get questions from folks who've tried to follow my instructions to create the content of TLSA records, but have failed because they are using a version of openssl that is too old to generate SHA-256 and SHA-512 hashes.<br />
<br />
I've written a small web application to help generate TLSA records. I hope this is of use to some folks:<br />
<br />
<a href="https://www.huque.com/bin/gen_tlsa">https://www.huque.com/bin/gen_tlsa</a><br />
<br />
(I apologize in advance for my rather primitive webpage design skills!)<br />
<br />
Here is a screenshot of it in action to generate the TLSA record for my own website:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY-NUoFXwMi3RVfc2g2uCuUIDW1bMQnXMadqnd4oOaoP7hyVdSEegM1qk7P-ThESOb1cV3waS1CzHa4R3AyoRRRQp3GlA7gyBlnFJzCty56sb01Pc2h2lY9w8TxnLNnGZgJya63PtaxMV1/s1600/p1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY-NUoFXwMi3RVfc2g2uCuUIDW1bMQnXMadqnd4oOaoP7hyVdSEegM1qk7P-ThESOb1cV3waS1CzHa4R3AyoRRRQp3GlA7gyBlnFJzCty56sb01Pc2h2lY9w8TxnLNnGZgJya63PtaxMV1/s640/p1.jpg" width="608" /></a></div>
<br />
And the resulting TLSA record that was generated:<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmE-p6yVB4y8_aJCFNpU6DvG8OfUyj2uDEDCVmUFE1X_0YLNCnNqlF5sLlPzpurECHVfkkQJo6mZ7aoW2e-KlJ1kfTgDX19BS-ixoVXUlVIR8ysGWCwsh4APQFtqJAVbccmJUVl1nDZMfC/s1600/p2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="328" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmE-p6yVB4y8_aJCFNpU6DvG8OfUyj2uDEDCVmUFE1X_0YLNCnNqlF5sLlPzpurECHVfkkQJo6mZ7aoW2e-KlJ1kfTgDX19BS-ixoVXUlVIR8ysGWCwsh4APQFtqJAVbccmJUVl1nDZMfC/s640/p2.jpg" width="640" /></a> <br />
<br />
-- Shumon Huque<br />
</div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com484tag:blogger.com,1999:blog-8235843539067563488.post-5476491449835314722013-10-22T13:17:00.001-04:002013-10-22T13:17:46.422-04:00IPv6 and DNSSEC at LISA in DC<div dir="ltr" style="text-align: left;" trbidi="on">
<a href="https://www.usenix.org/conference/lisa13"> <img alt="LISA '13" border="0" height="93" src="https://www.usenix.org/sites/default/files/lisa13_lucky_banner_450x93.png" width="450" /> </a>
<br />
<br />
Once again, I'm teaching a couple of courses at the <a href="https://www.usenix.org/conference/lisa13" target="_blank">USENIX LISA conference</a>, this time in Washington, DC. The first is a <a href="https://www.usenix.org/conference/lisa13/training-program/full-training-program#S5" target="_blank">half day course on DNSSEC</a> on Sunday, November 3rd. And the second is a <a href="https://www.usenix.org/conference/lisa13/training-program/full-training-program#M1" target="_blank">full day course on IPv6</a> on Monday, November 4th. I hope to see you there if you're interested in learning or talking about these topics. Early bird registration discounts for the conference end on October 22nd (sorry for the short notice).<br />
<br />
<a href="http://www.standalone-sysadmin.com/blog/" target="_blank">Matt Simmons (@standaloneSA)</a> interviewed me about both classes: <a href="https://www.usenix.org/blog/interview-shumon-huque-his-dnssec-class" target="_blank">DNSSEC</a> and <a href="https://www.usenix.org/blog/interview-lisa-trainer-shumon-huque-ipv6" target="_blank">IPv6</a>.<br />
<br />
-- Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com189tag:blogger.com,1999:blog-8235843539067563488.post-26251720859774355582013-10-03T22:06:00.000-04:002013-10-06T09:18:13.004-04:00Singh Nanotechnology Center<div dir="ltr" style="text-align: left;" trbidi="on">
The grand opening of Penn's new <a href="http://www.nano.upenn.edu/core-facilities/" target="_blank">Singh Center for Nanotechnology</a> is tomorrow (Friday, October 4th). Computing directors in my department got to see it a week early when we held a special meeting in the Forum room.<br />
<br />
This post contains a few photos from my visit - of the building exterior, hallways, and conference rooms. The labs weren't open yet. The <a href="https://plus.google.com/photos/105308234918217701741/albums/5929400115648834817" target="_blank">full set can be found at Google Plus</a>.<br />
<br />
The Nanotech center has been featured in some recent articles:<br />
<br />
* <a href="http://articles.philly.com/2013-09-21/entertainment/42254363_1_architects-fallingwater-western-pennsylvania" target="_blank">Philadelphia Inquirer - "Changing Skyline - Inga Saffron"</a><br />
* <a href="http://www.thedp.com/article/2013/09/singh-center-for-nanotechnology-open-october-4" target="_blank">The Daily Pennsylvanian</a><br />
* <a href="http://articles.philly.com/2013-10-04/news/42670271_1_penn-state-singh-center-glandt" target="_blank">Philadelphia Inquirer - "Penn going all out for small science"</a><br />
<br />
Building exterior, from Walnut Street close to the 33rd Street intersection, looking east:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-FM09aN6Aq6o/Ukl2OVOxUmI/AAAAAAAAIY0/dms7evSzZaY/s1600/P0081981.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="334" src="http://1.bp.blogspot.com/-FM09aN6Aq6o/Ukl2OVOxUmI/AAAAAAAAIY0/dms7evSzZaY/s640/P0081981.JPG" width="640" /></a></div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-yRlbTiNmk00/Ukl2Mlt1oCI/AAAAAAAAIYE/981BhmTGXGU/s1600/P0081975-2.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="272" src="http://4.bp.blogspot.com/-yRlbTiNmk00/Ukl2Mlt1oCI/AAAAAAAAIYE/981BhmTGXGU/s640/P0081975-2.JPG" width="640" /></a></div>
<br />
This cantilevered section houses a conference room - the Glandt Forum room.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-5QUC_AvjmRk/Ukl1_h-3f0I/AAAAAAAAISc/JiGjwaZya1M/s1600/P0081878.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="504" src="http://1.bp.blogspot.com/-5QUC_AvjmRk/Ukl1_h-3f0I/AAAAAAAAISc/JiGjwaZya1M/s640/P0081878.JPG" width="640" /></a></div>
<br />
The Forum room, where our meeting was held.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-2Os9tYLbuK8/Ukl2ATO59qI/AAAAAAAAIS8/aK9eV9bj6oE/s1600/P0081921.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://2.bp.blogspot.com/-2Os9tYLbuK8/Ukl2ATO59qI/AAAAAAAAIS8/aK9eV9bj6oE/s640/P0081921.JPG" width="640" /></a></div>
<br />
At the edge of the cantilevered section.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-eL5YgPz4Fdw/Ukl2BvPWgcI/AAAAAAAAITU/2_zQvBO2BW0/s1600/P0081927.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://4.bp.blogspot.com/-eL5YgPz4Fdw/Ukl2BvPWgcI/AAAAAAAAITU/2_zQvBO2BW0/s640/P0081927.JPG" width="640" /></a></div>
<br />
Looking westward along Walnut St towards the rest of campus. Directly in front (right side) is the Laboratory for Research on the Structure of Matter (LRSM). To the left is the David Rittenhouse Lab.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-NetrfapEpt4/Ukl2Bbkwo-I/AAAAAAAAITM/Io2LDFbqe38/s1600/P0081925.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://1.bp.blogspot.com/-NetrfapEpt4/Ukl2Bbkwo-I/AAAAAAAAITM/Io2LDFbqe38/s640/P0081925.JPG" width="640" /></a></div>
<br />
View from the green rooftop terrace.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-ffOkziHQQB4/Ukl2E9rCsSI/AAAAAAAAIUw/IrsmjScAPjo/s1600/P0081941.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://3.bp.blogspot.com/-ffOkziHQQB4/Ukl2E9rCsSI/AAAAAAAAIUw/IrsmjScAPjo/s640/P0081941.JPG" width="640" /></a></div>
<br />
Rooftop terrace.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-Iznf1z-53PQ/Ukl2Fsc8wMI/AAAAAAAAIVI/INa7Yx5_mCk/s1600/P0081944.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://4.bp.blogspot.com/-Iznf1z-53PQ/Ukl2Fsc8wMI/AAAAAAAAIVI/INa7Yx5_mCk/s640/P0081944.JPG" width="640" /></a></div>
<br />
Hallways.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-gdo_d7Qnios/Ukl2IQA0iHI/AAAAAAAAIWY/L3-sVS3INu0/s1600/P0081955.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://4.bp.blogspot.com/-gdo_d7Qnios/Ukl2IQA0iHI/AAAAAAAAIWY/L3-sVS3INu0/s640/P0081955.JPG" width="640" /></a></div>
<br />
"We Lost" sculpture by Tony Smith.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-9dMD_aPrGhU/Ukl2LA12ZAI/AAAAAAAAIXg/kgdhTo0gS4A/s1600/P0081969.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="426" src="http://3.bp.blogspot.com/-9dMD_aPrGhU/Ukl2LA12ZAI/AAAAAAAAIXg/kgdhTo0gS4A/s640/P0081969.JPG" width="640" /></a></div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-IrEq4uzx4FM/Ukl2ME8hwaI/AAAAAAAAIX0/zXlpXPJ2iew/s1600/P0081974.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="326" src="http://4.bp.blogspot.com/-IrEq4uzx4FM/Ukl2ME8hwaI/AAAAAAAAIX0/zXlpXPJ2iew/s640/P0081974.JPG" width="640" /></a></div>
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com166tag:blogger.com,1999:blog-8235843539067563488.post-81074208046532447562013-10-02T21:59:00.000-04:002013-10-04T08:30:03.271-04:00Latest World IPv6 Launch Measurements<div dir="ltr" style="text-align: left;" trbidi="on">
The Internet Society recently published results of their latest round (September 17th 2013) of <a href="http://www.worldipv6launch.org/measurements/" target="_blank">IPv6 measurements</a>. The measurement data is provided by Google, Facebook, Yahoo!, and Akamai. From the description on the website: "We present measurements of network operator participants in World IPv6
Launch, based on data received from major website participants, as
described in more detail below. We present a simple average of the data
received, and list all networks with measurements from at least two
sources, with a simple average above 0.1%."<br />
<br />
I find it instructive to sort the results by the percentage of requests from each participating network that are composed of IPv6. This is a pretty good indicator of how extensively these networks have deployed IPv6 to their end users.<br />
<br />
Note: the measurements are only done for networks that have signed up as participants in World IPv6 Launch. If you've deployed IPv6 to your users, you should consider <a href="http://www.worldipv6launch.org/form/" target="_blank">registering your network</a> to take part in these measurements. <br />
<br />
Here's a ranked list of these networks sorted by percentage of IPv6 requests of the total from each.<br />
<br />
<b><span style="font-family: "Courier New", Courier, monospace;"> 1 interscholz Internet Services GmbH & Co. KG 81.22%<br /> 2 Sauk Valley Community College 71.23%<br /> 3 ThaiSarn 69.41%<br /> 4 Rensselaer Polytechnic Institute 61.25%<br /> 5 Virginia Tech 59.54%<br /> 6 Universidad de Carabobo 58.50%<br /> 7 Sistemas Fratec S.A. 58.19%<br /> 8 Universidad Panamericana 57.89%<br /> 9 Bayu Krisnawan 56.64%<br /> 10 Dedicated Zone Inc 56.55%<br /> 11 Google Fiber 55.64%<br /> 12 REACCIUN 52.41%<br /> 13 NETIS TELECOM 52.17%<br /> 14 Gustavus Adolphus College 46.64%<br /> 15 DreamHost 46.32%<br /> 16 Alhambra Eidos 45.37%<br /> 17 VOO 45.32%<br /> 18 SPAWAR 45.28%<br /> 19 Greek Research & Technology Network 43.96%<br /> 20 Karlsruhe Institute of Technology (KIT) 43.51%<br /> 21 AIMES Grid Services CIC 42.37%<br /> 22 Host Virtual, Inc 42.24%<br /> 23 ARNES 41.90%<br /> 24 FCCN 40.95%<br /> 25 Marist College 40.89%<br /> 26 guifi.net 39.97%<br /> 27 University of Pennsylvania 38.94%<br /> 28 Zimcom Internet Solutions, Inc 35.75%<br /> 29 Verizon Wireless 35.73%<br /> 30 NIIF/Hungarnet 29.92%<br /> 31 LITNET 29.07%<br /> 32 DirectVPS 29.05%<br /> 33 Jiri strohalm 28.56%<br /> 34 Hughes Network Systems 28.00%<br /> 35 DegNet GmbH 26.76%<br /> 36 Louisiana State University 26.61%<br /> 37 University of Minnesota 26.44%<br /> 38 iway AG 25.73%<br /> 39 RedIRIS 25.39%<br /> 40 University of Iowa 22.56%<br /> 41 Universidade Federal de Santa Catarina, Brazil 22.26%<br /> 42 Cisco 22.14%<br /> 43 Monash University 21.82%<br /> 44 Hurricane Electric 21.80%<br /> 45 RENATER 21.55%<br /> 46 TUBITAK ULAKBIM / ULAKNET 21.46%<br /> 47 Aristotle University of Thessaloniki 20.89%<br /> 48 DataChambers 20.28%<br /> 49 UNESP 19.85%<br /> 50 Chubu Telecommunications 19.06%<br /> 51 Swisscom 18.83%<br /> 52 Indiana University 18.08%<br /> 53 Free 18.04%<br /> 54 FranTech Solutions 17.69%<br /> 55 Tulane University 17.55%<br /> 56 University of New Hampshire 17.45%<br /> 57 Leibniz Supercomputing Centre 16.60%<br /> 58 HEAnet 16.59%<br /> 59 US Dept of Transportation 16.55%<br /> 60 GARR 16.27%<br /> 61 XS4ALL 16.14%<br /> 62 Defense Research and Engineering Network 15.24%<br /> 63 DMZGlobal 14.26%<br /> 64 PCextreme B.V. 13.80%<br /> 65 RCS & RDS 13.25%<br /> 66 PowerTech Information Systems AS 12.24%<br /> 67 SURFnet 12.07%<br /> 68 BIT BV 11.93%<br /> 69 ATT 11.52%<br /> 70 Academia Sinica Network 11.34%<br /> 71 Honesty Net Solutions (I) Pvt Ltd 9.85%<br /> 72 UNINETT 9.48%<br /> 73 Storm Internet 9.25%<br /> 74 CESNET 9.18%<br /> 75 University Of Lampung 9.12%<br /> 76 AAISP 8.88%<br /> 77 prgmr.com 8.61%<br /> 78 KDDI 8.49%<br /> 79 Voxel / Internap 8.29%<br /> 80 Init7 8.19%<br /> 81 AMRES - Serbian National R&E Network 8.06%<br /> 82 Comcast 7.95%<br /> 83 CJSC Progressive Technologies 7.92%<br /> 84 MediaCat Div./Community Network Center Inc. 7.17%<br /> 85 green.ch AG 7.02%<br /> 86 StarHub 6.68%<br /> 87 OVH 6.30%<br /> 88 UniNet 6.26%<br /> 89 CORPORACION NACIONAL DE TELECOMUNICACIONES 6.02%<br /> 90 National Technical University of Athens 5.91%<br /> 91 Forthnet 5.81%<br /> 92 Deutsche Telekom AG 5.18%<br /> 93 EPT Luxembourg 5.11%<br /> 94 Energy Group Networks 4.62%<br /> 95 M1 Limited 4.56%<br /> 96 Internode 4.33%<br /> 97 BelWue 4.32%<br /> 98 Quonix Networks 4.26%<br /> 99 SMELLY BLACK DOG 4.22%<br /> 100 LENTEL 4.15%</span></b></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com46tag:blogger.com,1999:blog-8235843539067563488.post-43844823502254757872013-09-08T19:20:00.000-04:002013-09-08T20:20:06.490-04:00DNSSEC Validation in the Internet2 community<div dir="ltr" style="text-align: left;" trbidi="on">
As a follow-up to my <a href="http://blog.huque.com/2013/09/isc-dlv-registry-usage.html">examination of the ISC DLV registry</a>, I conducted an informal poll of some of my peers in the <a href="http://www.internet2.edu/">Internet2</a> community to find out 1) who is using DNSSEC validation on their resolvers, and 2) who additionally uses the ISC DLV.<br />
<br />
A while back I setup a small <a href="http://blog.huque.com/2012/07/targeted-survey-of-dnssec-deployment.html">project to monitor the status of DNS signed zones</a> in Internet2 and few other selected communities. There is no easy way to programmatically determine who is using DNSSEC validation though, so the easiest way is to ask others [1]. I got responses from a number of universities and regional R&E networks. Here's a summary:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"><u><b>Institution</b></u> <u><b>Uses ISC DLV?</b></u></span><br />
<span style="font-family: "Courier New",Courier,monospace;">University of Pennsylvania Yes <br />Virginia Tech Yes <br />Univ of California, Los Angeles No<br />Univ of Massachusetts, Amherst No<br />Kansas Research & Education Network Yes</span><br />
<span style="font-family: "Courier New",Courier,monospace;">Kansas State University <unknown><br />Fort Hays State University <unknown><br />Louisiana State University No<br />Univ of California, Berkeley Yes<br />Energy Sciences Network (ESNet) Yes<br />Lawrence Berkeley National Lab (LBNL) <unknown><br />North Dakota State University Yes<br />Univ of Delaware Yes</span><br />
<span style="font-family: "Courier New",Courier,monospace;">3ROX (3 Rivers Optical Exchange) Yes</span><br />
<span style="font-family: "Courier New",Courier,monospace;">Pittsburgh Supercomputing Center (PSC) <some resolvers></span><br />
<span style="font-family: "Courier New",Courier,monospace;">University of Idaho No </span><br />
<br />
I'm sure I'm missing others - I'll add to this list as I discover them. If you know of anyone, feel free to let me know! <br />
<br />
Footnotes: <br />
[1] Although Geoff Huston and others have <a href="http://www.circleid.com/posts/20130717_dns_dnssec_and_googles_public_dns_service/">conducted some large scale studies of validation use</a>, using a method of buying and analyzing ad impressions at popular websites, directing clients to carefully constructed URLs located in zones with differing DNSSEC signature statuses.<br />
<br />
-- Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com11tag:blogger.com,1999:blog-8235843539067563488.post-29158064796420211482013-09-01T14:40:00.000-04:002013-09-01T14:40:22.678-04:00ISC DLV registry usage<div dir="ltr" style="text-align: left;" trbidi="on">
On a LinkedIn forum, Dan York of the Internet Society recently asked a question about <a href="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=269066202&gid=1340467&goback=.nmp_*1_*1_*1_*1_*1_*1_*1_*1_*1_*1#commentID_null" target="_blank">who still uses the ISC DNSSEC Lookaside Validation (DLV) registry</a>. While commenting on the discussion, I decided to take a look at the contents of the registry, and I'm sharing some of my findings in this article.<br />
<br />
DLV is a method to locate DNSSEC public keys off-path. See <a href="http://tools.ietf.org/html/rfc5074" target="_blank">RFC 5074</a> and <a href="http://tools.ietf.org/html/rfc4431" target="_blank">RFC 4431</a> for details. It is meant to be an early deployment aid until full deployment of DNSSEC happens. It's useful in situations where the DNSSEC keys for a target zone cannot be obtained by the normal top down traversal of the DNS delegation hierarchy, typically because one or more zones between the target zone and the root aren't signed. Another situation is where a parent zone may be signed but it was not possible for the child zone to have a Delegation Signer (DS) record installed in the parent for some reason - a common one is that the DNS registrar in use did not support the ability to do it.<br />
<br />
<a href="http://www.isc.org/" target="_blank">Internet Systems Consortium (ISC)</a> runs a <a href="https://dlv.isc.org/">DLV registry at dlv.isc.org</a>. The basic idea is that if you can't find a DS record for a zone, say "example.org", you append the name of the DLV registry and look for DLV record at "example.org.dlv.isc.org" - the contents of the record are the same as would have been found at the DS record. Validating resolvers are pre-configured with the public key of the dlv.isc.org zone and use it to authenticate the signature associated with the DLV record.<br />
<br />
It appears that some large DNS resolver services like Google DNS and Comcast do not use any DLV registries for validation, so only zones that have an intact chain of trust can have their data validated. I'm not sure if ISC publishes any usage statistics for their DLV registry, but from casual discussion with colleagues in the US R&E community over the years, I know quite a number of universities that do have their campus resolvers configured to use it. We use it at the <a href="http://www.upenn.edu/">University of Pennsylvania</a> too.While upenn.edu is signed and has a secure delegation in its parent, there are some auxiliary zones that we run, like <a href="http://www.magpi.net/">magpi.net</a> that don't have a secure delegation, and we make use of the ISC DLV registry to publish keys there. In MAGPI's case, the reason is that the registrar we use, Network Solutions, still doesn't support DS records. I suppose it's time to switch registrars, and it's on my todo list!<br />
<br />
In modern versions of resolvers like <a href="http://www.isc.org/downloads/bind/">ISC BIND</a> and <a href="http://unbound.net/">Unbound</a>, a mere one line addition to the configuration file will turn this feature on. In fact, some OS distributions, like Fedora Linux already have it turned on in their default configuration.<br />
<br />
The ISC DLV zone by design uses NSEC, so it's trivial to write a short program to fully enumerate its contents and look at the data. Here's what I see from a snapshot of the zone taken on August 29th 2013:<br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;"> Number of distinct zones: 2760</span></b><br />
<b><span style="font-family: "Courier New",Courier,monospace;"> Total number of DLV records: 6020</span></b><br />
<br />
The number of DLV records is higher because most zones have multiple DLV records - their key digests are published with mutiple hashing algorithms (SHA1 and SHA256), and in some cases mutiple keys are published (perhaps key rollovers are in progress). Here's a breakdown of the number of DLV records per zone, and the number of zones with that many records: <br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;"> #DLV recs #Zones</span></b><br />
<b><span style="font-family: "Courier New",Courier,monospace;"> 8 1<br /> 6 3<br /> 4 241<br /> 2 2515</span></b><br />
<br />
The zone with 8 DLV records (!) incidentally is <b>hysh.jp</b> (4 keys, 2 digests/key).<br />
<br />
Looking at the distribution of zones across Top Level Domains (TLD), we see:<br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;"> Number of TLDs represented: 111</span></b><br />
<br />
There are 318 total TLDs at the current time, 116 of which appear to be signed, so that leaves 202 that aren't. I maintain some more detailed statistics of the TLDs at <a href="http://www.huque.com/app/dnsstat/category/tld/">http://www.huque.com/app/dnsstat/category/tld/</a><br />
<br />
Here's the full list of the 111 TLDs represented, sorted by descending order of the number of zones within them that are in the ISC DLV registry.<br />
<span style="font-family: "Courier New",Courier,monospace;"><br /><b> arpa 487<br /> com 456<br /> org 270<br /> net 263<br /> de 185<br /> info 75<br /> eu 67<br /> uk 66<br /> ch 50<br /> hu 49<br /> ro 34<br /> us 34<br /> cz 32<br /> za 31<br /> pl 31<br /> fr 29<br /> ru 28<br /> ca 28<br /> it 26<br /> biz 25<br /> be 25<br /> au 25<br /> nl 24<br /> jp 22<br /> id 22<br /> name 20<br /> me 20<br /> mx 19<br /> tv 18<br /> at 17<br /> edu 16<br /> tw 13<br /> tk 12<br /> es 12<br /> mobi 11<br /> br 10<br /> cx 10<br /> co 8<br /> is 8<br /> nu 8<br /> fi 8<br /> sk 8<br /> dk 7<br /> se 7<br /> gov 6<br /> im 6<br /> ua 6<br /> am 6<br /> asia 5<br /> ws 5<br /> cc 5<br /> in 5<br /> nz 5<br /> xn--p1ai 5<br /> pt 4<br /> gs 3<br /> do 3<br /> bz 3<br /> cn 3<br /> hr 3<br /> ms 3<br /> ve 3<br /> mil 3<br /> nf 3<br /> gm 2<br /> lc 2<br /> la 2<br /> li 2<br /> th 2<br /> ph 2<br /> hn 2<br /> mu 2<br /> pro 2<br /> ar 2<br /> io 2<br /> ni 2<br /> gr 1<br /> gp 1<br /> lv 1<br /> to 1<br /> tl 1<br /> lu 1<br /> tj 1<br /> tg 1<br /> ec 1<br /> rs 1<br /> re 1<br /> jobs 1<br /> cm 1<br /> int 1<br /> tm 1<br /> pe 1<br /> pn 1<br /> aero 1<br /> hk 1<br /> md 1<br /> mg 1<br /> uy 1<br /> mw 1<br /> ug 1<br /> vc 1<br /> ae 1<br /> ai 1<br /> al 1<br /> vn 1<br /> as 1<br /> xxx 1<br /> kg 1<br /> sr 1<br /> st 1<br /> kr 1</b></span><br />
<br />
Interestingly of the 2760 zones, <b>653 of them (almost a quarter!) also have DS records</b> in their parent zones, so technically they don't need to be in the DLV registry at all. This includes three TLDs: <b>th</b>, <b>ua</b>, and <b>kg</b>. I wonder what the motivation for additionally maintaining keys in a DLV registry is. One theoretical reason might be to have an off-path database of keys that could be audited in case of an attack in the normal delegation chain.<br />
<br />
Below are the sixteen zones inside .EDU:<br />
<br />
<b><span style="font-family: "Courier New",Courier,monospace;"> bucknell.edu DS exists<br /> internet2.edu DS exists<br /> k-state.edu DS exists<br /> cs.kent.edu kent.edu not signed<br /> ksu.edu DS exists<br /> ai.mit.edu mit.edu not signed<br /> csail.mit.edu mit.edu not signed<br /> dlp.mit.edu mit.edu not signed<br /> lcs.mit.edu mit.edu not signed<br /> npitest.psu.edu psu.edu not signed<br /> ualr.edu DS exists<br /> ucaid.edu DS exists<br /> cse.ucdavis.edu DS exists<br /> math.ucdavis.edu DS exists<br /> ucr.edu DS exists<br /> maf.wisc.edu wisc.edu not signed</span></b><br />
<b><span style="font-family: "Courier New",Courier,monospace;"><br /></span></b>
The EDU TLD is signed and has single registrar (Educause) that has supported DNSSEC for a long time. All the second level domains in the list above also have DS records in EDU, so they don't really need to also have DLV records. Most of the third level domains (one at Kent State U, four at MIT, one at Penn State, and one at U of Wisconsin) have parents that are not yet signed, so that makes sense. However, the two third level domains, cse.ucdavis.edu and math.ucdavis.edu have DS records in ucdavis.edu, so don't need DLV records either.<br />
<br />
Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com27tag:blogger.com,1999:blog-8235843539067563488.post-19588610678659625012013-07-28T22:55:00.000-04:002013-07-28T22:55:02.811-04:00Network Engineer Job at Penn<div dir="ltr" style="text-align: left;" trbidi="on">
We have an opening for a Senior Network Engineer in the <a href="http://www.upenn.edu/" target="_blank">University of Pennsylvania</a>'s Engineering group.<br />
<br />
<a href="https://jobs.hr.upenn.edu/applicants/Central?quickFind=197742">https://jobs.hr.upenn.edu/applicants/Central?quickFind=197742</a><br />
<br />
This position will be part of a small team that works very closely with our Network Operations group, offering final
tier escalated support, researching new network designs, architectures & technologies, evaluating new equipment, designing and deploying related
software and hardware systems.<br />
<br />
The Engineering group
is also involved in designing and operating a range of other services, including DNS, DHCP, Authentication & Authorization systems, Voice over IP, etc. So there are opportunities to get involved in many areas.<br />
<br />
The candidate for this position
will generally need to have a strong networking <b>and</b> programming background, as well as strong familiarity with UNIX and UNIX-like operating systems.<br />
<br />
</div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com5tag:blogger.com,1999:blog-8235843539067563488.post-53885574200269840952013-06-14T09:09:00.003-04:002013-06-14T09:09:39.312-04:00LOPSA East Class reviews - IPv6 & DNSSEC<div dir="ltr" style="text-align: left;" trbidi="on">
I just received the reviews and attendee feedback for the IPv6 and DNSSEC classes I taught at the recent <a href="http://lopsa-east.org/2013/" target="_blank">LOPSA-East conference</a>. So far my recent stint as a technical course instructor at various conferences has been going well. Students are generally very pleased with the courses, and the positive feedback often results in invitations to teach at other venues.<br />
<br />
The DNSSEC class is new. At past conferences, I've taught a combined DNS and DNSSEC class. But I've received feedback that many folks would like to see a course focussed on DNSSEC, so I created one. I also incorporated some live demos of setting up DNSSEC, which attendees found to be very useful.<br />
<br />
I'll most likely be teaching these classes again at the <a href="https://www.usenix.org/conference/lisa13" target="_blank">USENIX LISA conference</a> in Washington, DC later this year.<br />
<br />
The possible responses for each question in the feedback survey are "Unsatisfactory", "Missed Some Expectations", "Met Expectations", "Exceeded Expectations", and "Greatly Exceeded Expectations". The data below is only for the (small) subset of the class that offered feedback of course. <br />
<br />
<h3 style="text-align: left;">
IPv6 Course Feedback</h3>
<br />
==> SA1: Using and Migrating to IPv6 / Huque<br />
<br />
Rate this training session: [Description matched the contents of the class]<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Met Expectations<br />
* Met Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Class material was useful to my job]<br />
* Greatly Exceeded Expectations<br />
* Met Expectations<br />
* Greatly Exceeded Expectations<br />
* Met Expectations<br />
* Met Expectations<br />
* Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Instructor was knowledgeable]<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Instructor was able to answer students questions]<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Course material quality]<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
What was the single BEST part of this class?<br />
* good material, awesome presenter<br />
* Excellent balance of technical detail with beginner introduction<br />
* instructor clear experience and ability to communicate topic<br />
* He has done the work, and could provide many answer from experience<br />
* Quality of the instructor - good speaker and very knowledgable.<br />
*<br />
* The instructor was able to explain a very complex topic clearly & in terms that are directly applicable to my future use of the material.<br />
* Shumon's depth of knowledge; he adapted what we covered and how fast we were going, on the fly! AWESOME instructor.<br />
<br />
Name one aspect of this class that NEEDS IMPROVMENT?<br />
* needs to be longer<br />
*<br />
* wants more time to work in.<br />
* pacing, which material to emphasis. I thought the first part of the material could have been covered a bit faster, and more time on the meatier issues<br />
* The class seemed to detail a lot of 'differences between ipv6 and ipv4' and protocol internals in favor of 'how do I actually deal with migration issues'. A better mix would be nice, but I understand that unless you know of the differences, it can be hard to concentrate on implementation.<br />
*<br />
* Access to a Lab for a demo might add to the session.<br />
* nothing, run this class again. MAYBE, talk him into making another class focused on migrating your organization from v4 to v6... so people can do 'intro to ipv6' if they need, then another session on migration strategies.<br />
<br />
Should LOPSA offer this class in the furture?<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
<br />
<h3 style="text-align: left;">
DNSSEC Course Feedback</h3>
<br />
==> SA4: DNSSEC (DNS Security Extensions) / Huque<br />
<br />
Rate this training session: [Description matched the contents of the class]<br />
* Met Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Class material was useful to my job]<br />
* Met Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Instructor was knowledgeable]<br />
* Met Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Instructor was able to answer students questions]<br />
* Met Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
Rate this training session: [Course material quality]<br />
* Met Expectations<br />
* Missed Some Expectations<br />
* Greatly Exceeded Expectations<br />
* Exceeded Expectations<br />
* Greatly Exceeded Expectations<br />
<br />
What was the single BEST part of this class?<br />
* DNSSEC appears do-able<br />
* My impression of DNSSEC went from theoretically possible to practical in a very short time. Something that is alluded me for quite some time.<br />
*<br />
* Best part was seeing the live application of theory in an enterprise environment.<br />
* Shumon's depth of knowledge; he adapted what we covered and how fast we were going, on the fly! AWESOME instructor. He's so good, we had wonky wifi, and he just ran demos through Bind on his Mac. nice.<br />
<br />
Name one aspect of this class that NEEDS IMPROVMENT?<br />
*<br />
* Materials were not but will be posted to the presenters site<br />
*<br />
* nothing negative to say.<br />
* nothing, don't change anything, run it again!<br />
<br />
Should LOPSA offer this class in the furture?<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
* Yes<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com7tag:blogger.com,1999:blog-8235843539067563488.post-27117122432960671642013-06-10T17:45:00.000-04:002013-06-13T21:28:11.740-04:00100 Gigabit Ethernet at Penn<div dir="ltr" style="text-align: left;" trbidi="on">
This summer, the <a href="http://www.upenn.edu/" target="_blank">University of Pennsylvania</a> is upgrading its campus core routing equipment (in fact we're in the midst of this upgrade right now). This is basically an upgrade to the set of large routers that form the center of our network.<br />
<br />
The current core topology consists of 5 core routers (and also 2 border routers) interconnected by two independent layer-2 switched 10 Gigabit Ethernet networks. Each of the core routers is located in one of five geographically distributed machine rooms across the campus. A rough diagram is shown below.<br />
<br />
This diagram also shows the current external connections to/from the campus network - we have three links (each 10 Gigabit Ethernet) to Internet Service Providers (ISPs). And two connections to <a href="http://www.magpi.net/" target="_blank">MAGPI</a> (the regional Internet2 GigaPoP operated by us), via which we access a 10 Gigabit Ethernet connection to Internet2. The <a href="http://www.internet2.edu/" target="_blank">Internet2</a> connection is shared amongst Penn and other MAGPI customers, which are mostly Research & Education institutions in the geographic area.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgivrZnnwpPrqdsBcWeKyWRUcTiHd5r13fBlK1py9o8MIjSgwQ_BzMD548dt0QEJECoRJNwCdvdIsGTSrWTXnJrmj4M2bXMyWGErAcF5pr6JNuDSOweHWr9S_NZsTfGDQ6Zw8nfapjzBKUq/s1600/2013-06-PennNet-old-generic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="366" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgivrZnnwpPrqdsBcWeKyWRUcTiHd5r13fBlK1py9o8MIjSgwQ_BzMD548dt0QEJECoRJNwCdvdIsGTSrWTXnJrmj4M2bXMyWGErAcF5pr6JNuDSOweHWr9S_NZsTfGDQ6Zw8nfapjzBKUq/s640/2013-06-PennNet-old-generic.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
The core interconnect is being upgraded to <a href="http://en.wikipedia.org/wiki/100_Gigabit_Ethernet" target="_blank"><b>100 Gigabit Ethernet</b></a> (a ten-fold increase in link bandwidth). It would be cost prohibitive to fully replicate the current design in 100 Gig (since this equipment is still very expensive) so the interconnect design has been adjusted a bit. Instead of two layer-2 switch fabrics interconnecting the routers, we are deploying the core routers connected in a 100 Gig ring (see the diagram below). When the final design is fully implemented, each core router will have a 10 Gig connection into each of the border routers (this will require some additional upgrades to the border routers, which are expected to happen later this year). The topology redesign has fewer links, and in the final count (summing the bandwidth of all the core facing links), the new core will have about 5 times the aggregate bandwidth of the old one. The maximum (shortest path) edge to edge diameter of the network increases by one routing hop.<br />
<br />
100 Gigabit Ethernet is today's state of the art in transmission speed. The next jump up will likely be 400 Gigabit Ethernet for which the <a href="http://www.ieee.org/" target="_blank">IEEE</a> already has a study group launched and several preliminary designs under consideration.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU5yUqss7rqlyW8tR5eN1AqgbWlJ06dDz-Xye_QyEk8YfnzY2n_lncgqcxzIErNW0X5oLIr9ZwZRkHfs0htC6HJm2myd8vyj2HTQp8Md_7yjtk75ClvIe94EOA3hdBoNJ1DkHvnPA_7ajV/s1600/2013-06-PennNet-generic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="358" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjU5yUqss7rqlyW8tR5eN1AqgbWlJ06dDz-Xye_QyEk8YfnzY2n_lncgqcxzIErNW0X5oLIr9ZwZRkHfs0htC6HJm2myd8vyj2HTQp8Md_7yjtk75ClvIe94EOA3hdBoNJ1DkHvnPA_7ajV/s640/2013-06-PennNet-generic.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
Not depicted in this diagram is the rest of the network towards the end systems. Below the layer of core routers, are smaller routers located at the 200 or so buildings scattered around campus. Each building router is connected to two of the core routers. The building routers feed wiring closets inside the building, which house layer-2 switches that network wallplates are connected to.<br />
<br />
In the process of the upgrade, we are also changing router vendors. The current core routers, <a href="http://www.cisco.com/en/US/products/hw/routers/ps368/ps367/index.html" target="_blank">Cisco 7609 series routers</a> with Sup7203BXL supervisor engines, have served us well. They were originally deployed in the summer of 2005, and have been in operation well past their expected lifetime.<br />
<br />
As is our practice, we issued an RFI/P (Request for Information/Purchase) detailing our technical requirements for the next generation routers and solicited responses from the usual suspects, selecting a few vendors whose equipment we bring in for lab testing, followed by a selection.<br />
<br />
The product we've selected is the <b><a href="http://www.brocade.com/" target="_blank">Brocade</a></b> <b>MLXe series router</b>, specifically the MLXe-16 - this router can support 16 half height, or 8 full height (or a mixture of full/half) line cards, as well as redundant management and switch fabric modules.<br />
<br />
A product description of the MLXe series is available at:<br />
<a href="http://www.brocade.com/downloads/documents/data_sheets/product_data_sheets/MLX_Series_DS.pdf">http://www.brocade.com/downloads/documents/data_sheets/product_data_sheets/MLX_Series_DS.pdf</a><br />
<br />
The photo below is one of the routers (prior to deployment) in the Vagelos node room (one of 5 machine rooms distributed around campus where we house critical networking equipment and servers).Going from left to right, this chassis has two management modules, one 2-port 100 Gigabit Ethernet card, six 8-port 10 Gigabit Ethernet cards, four switch fabric modules, two more 8-port 10 Gigabit Ethernet cards, and three 24-port Gigabit Ethernet cards.<br />
<br />
One of these routers was deployed in production last week. The rest should be up and running by the end of this month or by early July. <br />
<br />
(<a href="https://plus.google.com/photos/105308234918217701741/albums/5884319817705645729" target="_blank">The full set of photos can be seen here on Google Plus</a>)<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-NePUDfY1lhc/UalNx-QfQGI/AAAAAAAAF-s/spj4nPMPIiU/s1600/IMG_0896.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://4.bp.blogspot.com/-NePUDfY1lhc/UalNx-QfQGI/AAAAAAAAF-s/spj4nPMPIiU/s640/IMG_0896.JPG" width="480" /></a></div>
<br />
<br />
Shown below is the 2-port 100 Gigabit Ethernet card, partially inserted into the chassis, showing the CFP optical transceiver modules attached. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-g8qv1-tJvjg/UalNs2kvkyI/AAAAAAAAF90/2PQA2ugRf8o/s1600/IMG_0886.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://2.bp.blogspot.com/-g8qv1-tJvjg/UalNs2kvkyI/AAAAAAAAF90/2PQA2ugRf8o/s640/IMG_0886.JPG" width="480" /></a></div>
<br />
<br />
Unlike preceding generations of ethernet, with 100 Gigabit Ethernet, the transmission technology uses multiple wavelengths in parallel (although there are parallel fiber implementations also). The current IEEE specifications (802.3ba) specify four lanes of 25Gbps. However a number of key vendors in the industry, including Brocade, formed the MSA (Multi Source Agreement) and designed and built a 10x10 (10 lanes of 10Gbps) mechanism of doing 100 Gig, at much lower cost than 4x25Gbps, operating over single mode fiber at distances of 2, 4, or 10km. This is called LR-10 and uses the CFP (C Form factor pluggable) media type.<br />
<br />
Pictured below (left) is a Brocade LR10 100 Gigabit Ethernet CFP optical module installed in 100 Gig line card with a single mode fiber connection (LC). On the right is an LR10 CFP module taken out of the router. <br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-KUkfBWOYS7Q/UalNwHmuOkI/AAAAAAAAF-Q/L4FIH0xjeQw/s1600/IMG_0891.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="240" src="http://1.bp.blogspot.com/-KUkfBWOYS7Q/UalNwHmuOkI/AAAAAAAAF-Q/L4FIH0xjeQw/s320/IMG_0891.JPG" width="320" /></a><a href="http://2.bp.blogspot.com/-vEUAmUmj6wg/UalNxhUig3I/AAAAAAAAF-o/nK38KF2fFzo/s1600/IMG_0894.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://2.bp.blogspot.com/-vEUAmUmj6wg/UalNxhUig3I/AAAAAAAAF-o/nK38KF2fFzo/s320/IMG_0894.JPG" width="240" /></a></div>
<br />
<br />
Close up of the 8-port 10 Gigabit Ethernet module, and several 24-port Gigabit Ethernet modules. To connect cables to them, we need to install small form factor pluggable transceivers into them, SFP+ for the 10 gig, and SFP for the 1 gig.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-neDqjxCx86I/UalN2Gkk-0I/AAAAAAAAF_8/wyX8tHtC11Q/s1600/IMG_0907.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="http://4.bp.blogspot.com/-neDqjxCx86I/UalN2Gkk-0I/AAAAAAAAF_8/wyX8tHtC11Q/s320/IMG_0907.JPG" width="240" /></a><a href="http://3.bp.blogspot.com/-Pvqvb6xq56A/UalN1utNXZI/AAAAAAAAF_0/jQLrK82NGuo/s1600/IMG_0906.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://3.bp.blogspot.com/-Pvqvb6xq56A/UalN1utNXZI/AAAAAAAAF_0/jQLrK82NGuo/s320/IMG_0906.JPG" width="240" /></a></div>
<br />
<br />
Pictured below is one of the five Cisco 7609 routers that will be replaced.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-q4nJatogWWQ/UalN7OLO6pI/AAAAAAAAGBo/t9oqexW_t-A/s1600/IMG_0931.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://4.bp.blogspot.com/-q4nJatogWWQ/UalN7OLO6pI/AAAAAAAAGBo/t9oqexW_t-A/s640/IMG_0931.JPG" width="480" /></a></div>
<br />
<br />
One of the Penn campus border routers, a Juniper M120, is shown below. This is also scheduled to be upgraded in the near future to accommodate 100 Gig and higher density 10 Gig, although the product has not yet been selected/finalized.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-ddKc239KjrM/UalN4yBt86I/AAAAAAAAGA0/uc2wUQXMHHM/s1600/IMG_0916.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="http://1.bp.blogspot.com/-ddKc239KjrM/UalN4yBt86I/AAAAAAAAGA0/uc2wUQXMHHM/s640/IMG_0916.JPG" width="480" /></a></div>
<br />
<br />
Below: A Ciena dense wavelength division multiplexer (DWDM). Penn uses leased metropolitan fiber to reach equipment and carriers in 401 North Broad street, the major carrier hotel in downtown Philadelphia. We have DWDM equipment placed both at the campus and the carrier hotel to carry a mixture of 1 and 10 Gig circuits and connections across this fiber for various purposes. This equipment is also scheduled to be upgraded to allow us to provision 100 Gigabit Ethernet wavelengths between the campus and the carrier hotel. <br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-WS4ypL-nm9w/UalN5Kr-eHI/AAAAAAAAGBA/6686hLwFltM/s1600/IMG_0917.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="http://1.bp.blogspot.com/-WS4ypL-nm9w/UalN5Kr-eHI/AAAAAAAAGBA/6686hLwFltM/s640/IMG_0917.JPG" width="640" /></a></div>
<br />
<br />
<h3 style="text-align: left;">
High Performance Networking for Researchers</h3>
<br />
Penn is a participant in the <a href="http://www.nsf.gov/" target="_blank">National Science Foundation (NSF)</a> funded <a href="http://www.internet2.edu/ion/dynes.html" target="_blank">DYNES (Dynamic Network Systems) project</a>, which provides high bandwidth dedicated point to point circuits between (typically) research labs for specialized applications. Popular uses of this infrastructure today include high energy physics researchers obtaining data from the <a href="http://home.web.cern.ch/about/accelerators/large-hadron-collider" target="_blank">LHC</a> and other particle accelerator labs, and various <a href="http://www.geni.net/" target="_blank">NSF GENI</a> network research projects.<br />
<br />
Earlier this year, we completed a grant application for the <a href="http://www.nsf.gov/pubs/2013/nsf13530/nsf13530.htm" target="_blank">NSF "Campus Cyberinfrastructure - Network Infrastructure and Engineering (CC-NIE)" program</a>. I spent a large amount of time in March of this year with several Penn colleagues in preparing the application. If Penn does win an award (we'll find out later this year), we will be deploying additional dedicated network infrastructure for campus researchers, bypassing the campus core and with 100 Gbps connectivity out to the Internet2 R&E network. A rough diagram of how this will look is below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyj7bV5csEkXhu9PypIxO6ghldQZfmmWgJYQIGWFv0zMVkC4mV6G-oLABUtO8utK4t2OASjXYZ_Ev8UCj6MONae7rrEwUZsAQD8pbpEsNm4u56j7KiEmuAOWajmDRPun_uW01w0pP2l-OK/s1600/NSF-CCNIE-Design1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="458" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyj7bV5csEkXhu9PypIxO6ghldQZfmmWgJYQIGWFv0zMVkC4mV6G-oLABUtO8utK4t2OASjXYZ_Ev8UCj6MONae7rrEwUZsAQD8pbpEsNm4u56j7KiEmuAOWajmDRPun_uW01w0pP2l-OK/s640/NSF-CCNIE-Design1.jpg" width="640" /></a></div>
<br />
<br />
<h3 style="text-align: left;">
Software Defined Networking</h3>
<br />
There's a huge amount of buzz about <a href="http://en.wikipedia.org/wiki/Software-defined_networking" target="_blank">Software Defined Networking (SDN)</a> in the networking industry today, and a number of universities are investigating SDN enabled equipment for deployment in their networks. Of the big router vendors, Brocade does appear to have one of the better SDN/openflow stories thus far. The MLXe series already supports an early version of <a href="https://www.opennetworking.org/sdn-resources/onf-specifications/openflow" target="_blank">Openflow</a> (the portion of SDN that allows forwarding tables of switches/routers to be programmed by an external SDN controller).<br />
<br />
Penn is building an SDN testbed in our network engineering lab, primarily to investigate its capabilities. For us, SDN is still largely a solution in search of a problem. We run a very simple network by design, whose primary purpose is connectivity and high performance packet delivery. The most probable use case in our future, virtualization of the network, is likely better achieved with a proven technology like MPLS first. But we'll keep an eye on SDN and its evolution. We do want to support research uses of SDN though. Several faculty members in the Computer Science department are interested in SDN, and the NSF CC-NIE grant will allow us to build some SDN enabled network infrastructure separate from the core production network to accommodate their work.<br />
<br />
-- Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com46tag:blogger.com,1999:blog-8235843539067563488.post-15954660212696439812013-06-02T22:16:00.000-04:002013-06-07T22:42:18.300-04:00Former Student to Caltech and CERN<div dir="ltr" style="text-align: left;" trbidi="on">
In addition to my full time job, I sometimes teach a course in <a href="http://www.seas.upenn.edu/" target="_blank">Penn's Engineering School</a> - specifically a Telecom Lab course on network protocols (mostly routing). The material covered in the course includes interior routing protocols like RIP, OSPF, and IS-IS; BGP for exterior routing; Multicast Routing; and MPLS (traffic engineering, Layer-2 and Layer-3 VPNs). I also cover the DNS and DHCP protocols in a fair amount of detail. All the lab assignments use both IPv4 and IPv6 extensively.<br />
<br />
Indira is one of my former students, and also served as my teaching assistant the semester following the one during which she took the class. She just graduated (Masters Degree in Telecommunications) and is moving to Geneva, Switzerland for a full time job. She stopped in to see me last week on the day she was leaving and we snapped a few photos together.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-Rq7iwrKPozQ/UavZkyU6RZI/AAAAAAAAGJY/4bEeOQLG2ZA/s1600/IMG_0860.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://4.bp.blogspot.com/-Rq7iwrKPozQ/UavZkyU6RZI/AAAAAAAAGJY/4bEeOQLG2ZA/s400/IMG_0860.JPG" width="400" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-0VwLKUPdcxY/UavZk-ANplI/AAAAAAAAGJc/5cNgM5mHzOA/s1600/IMG_0864.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://3.bp.blogspot.com/-0VwLKUPdcxY/UavZk-ANplI/AAAAAAAAGJc/5cNgM5mHzOA/s400/IMG_0864.JPG" width="400" /></a></div>
<br />
The job is a full time network engineer position with <a href="http://www.caltech.edu/" target="_blank">Caltech</a>, but based at <a href="http://home.web.cern.ch/" target="_blank">CERN</a> in Switzerland, working with some Caltech colleagues I know (Artur Barczyk, Azher Mughal, <a href="http://www.caltech.edu/expert/3138" target="_blank">Harvey Newman</a>) from <a href="http://www.internet2.edu/" target="_blank">Internet2</a> and various other R&E conferences. Among other things, Caltech is involved in operating <a href="http://lhcnet.caltech.edu/" target="_blank">USLHCNet</a>, a very high speed network that provides transatlantic connectivity between computing facilities at CERN's <a href="http://home.web.cern.ch/about/accelerators/large-hadron-collider" target="_blank">Large Hadron Collider (LHC)</a> and computing facilities at major US particle accelerator labs like Fermilab and Brookhaven.<br />
<br />
Harvey was also one of the principal investigators for the NSF funded <a href="http://www.internet2.edu/ion/dynes.html" target="_blank">DYNES (Dynamic Network System) project</a>, of which Penn is a participant. DYNES, via the Internet2 network infrastructure, provides dynamically allocated dedicated point to point circuits between remote research labs (a common endpoint is the LHC). Penn researchers were involved in building the LHC's ATLAS detector, and <a href="http://www.upenn.edu/pennnews/current/2012-07-05/features/penn-plays-role-large-hadron-collider%E2%80%99s-discovery-new-particle" target="_blank">played a role in the Higgs particle discovery last year</a>.<br />
<br />
Congratulations and good luck to Indira - I'm sure she has a bright and productive career ahead of her. She left me a small gift - a box of chocolates from Kazakhstan, pictured below. The box is almost too attractive to open, so I haven't yet.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-58RFIkQaV6o/UavZpevifqI/AAAAAAAAGKY/DbyBkSKhL0g/s1600/IMG_0877.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://3.bp.blogspot.com/-58RFIkQaV6o/UavZpevifqI/AAAAAAAAGKY/DbyBkSKhL0g/s400/IMG_0877.JPG" width="400" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-p6VG1jjoVn4/UavZpkkg2PI/AAAAAAAAGKc/EHi_pZG76nQ/s1600/IMG_0878.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://3.bp.blogspot.com/-p6VG1jjoVn4/UavZpkkg2PI/AAAAAAAAGKc/EHi_pZG76nQ/s400/IMG_0878.JPG" width="400" /></a></div>
<br />
Another talented former student and Teaching Assistant, Sangeetha had been working for me part time in Penn's Networking department on various projects. She also recently left (due to her advisor leaving Penn), transferring into the Ph.D program (CS) at the <a href="http://illinois.edu/" target="_blank">UIUC</a>.<br />
<br />
I'm planning to cancel my teaching appointment, since I don't really have the time for it, given the demands of my full time job. I originally decided to teach the course as a favor to my colleague, <a href="http://www.seas.upenn.edu/~guerin/" target="_blank">Roch Guerin</a>, but it's actually been quite a fun and rewarding experience for me (and hopefully my students). However, now that Roch is leaving Penn to take the <a href="https://www.alumni.caltech.edu/alumni_in_news/504" target="_blank">CS department chair position at the University of Washington at St. Louis</a>, it looks like Penn is winding down the TCOM program anyway - a good time for me to make an exit.<br />
<br />
I'm planning to write a more detailed blog post about my teaching experience at Penn. More on that later.<br />
<br />
--Shumon Huque.</div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com29tag:blogger.com,1999:blog-8235843539067563488.post-58112978052044483982013-04-13T10:24:00.000-04:002013-04-13T12:22:51.242-04:00DNS Amplification Attacks<div dir="ltr" style="text-align: left;" trbidi="on">
There has been a lot of talk recently about <i><b>DNS amplification attacks</b></i> (with prominent news reports of high bandwidth attacks targeted at anti-spam services, cloud providers, financial institutions, etc). These are a class of denial of service attack that use DNS servers to emit large amounts of traffic onto unsuspecting victims. The attackers use the forged source addresses of their victims to send a large stream of queries to the DNS servers, and this results in a much larger stream of responses being sent from those DNS servers back to the victim computers - with the aim of overwhelming them or their network connections. Although the DNS servers employed in the attack can become adversely impacted, the primary target of the attacks are the computers whose addresses are being forged.<br />
<br />
Attacks that employ IP source address forgery are effective on the Internet today, because the countermeasures that would prevent this forgery are not very widely deployed. <a href="http://tools.ietf.org/html/bcp38" target="_blank">BCP 38</a> (a 13 year old document!) and <a href="http://tools.ietf.org/html/bcp84" target="_blank">BCP 84</a> describe <i><b>network ingress filtering</b></i> as a way for ISPs to block forged traffic from their customer networks, but many ISPs fail to employ it. Organizations should also ideally configure their networks not to permit internally generated traffic with forged addresses from crossing their borders - typically a border Access Control List or more granular techniques like unicast reverse path forwarding (URPF, a per-subnet level antispoofing method) can be used to do this, but once again, these are not in very widespread use.<br />
<br />
In the past, the attacks commonly employed 'open recursive DNS resolvers' - these are DNS recursive resolvers that will resolve names for any client computer without restriction. When such servers are available, the attacker can use a DNS record of their choosing (possibly under the attackers control) that intentionally generates a very large response. To prevent such abuse, many organizations these days lock down their recursive resolvers so that they answer requests only from clients on their own networks. Penn does this also. There are however public DNS resolver services, like Google DNS, and OpenDNS, that by design are open to the world, and so need to have effective countermeasures in place to deal with these potential attacks. Both <a href="https://developers.google.com/speed/public-dns/docs/security" target="_blank">Google</a> and OpenDNS say that they do.<br />
<br />
There are still a huge number of open recursive DNS resolvers on the Internet, the vast majority of which are probably unintentionally so. The <a href="http://openresolverproject.org/" target="_blank">Open DNS Resolver Project</a> has been cataloging them and reports a number in the neighborhood of 25 million!<br />
<br />
But authoritative DNS servers (which need to be open to the world) are also quite vulnerable to amplification attacks. In this case, the attacker cannot choose an arbitrary DNS record, but instead must use only records that already exist in the authoritative server's zones. However, DNS responses are usually always amplifying (ie. the size of the response is a lot larger than the size of the request), so it's only a question of the scale of attack that can be achieved.<br />
<br />
Interestingly, DNSSEC, a security enhancement to the DNS protocol, makes the amplification problem significantly worse, since DNS responses with cryptographic signatures are much bigger than normal, unsigned DNS responses. Hence lately, we've been seing a lot of these attacks target authoritative servers with zones that are signed with DNSSEC.<br />
<br />
<a href="http://www.upenn.edu/" target="_blank">Penn</a> was one of the earliest organizations to deploy DNSSEC (August 2009, well before the root and most of the TLDs were signed). We first noticed such attacks on our authoritative servers in July of last year (2012) - at that time we didn't have a good way to counteract these, but our server and network infrastructure was easily able to absorb the attacks, so we didn't take any action - the attacks continued for a few weeks and then disappeared. In late January 2013 though, a new round of amplification attacks happened on a much larger scale that did negatively affect our infrastructure, causing high load on two of our servers and almost saturating the outbound bandwidth on their network connections. By this time, code to implement an experimental response rate limiting countermeasure was available (see Vernon Schryver and Paul Vixie's <a href="http://www.redbarn.org/dns/ratelimits" target="_blank">Response Rate Limiting (RRL)</a> -- implementations are available for popular DNS server software such as BIND, NSD, etc). We deployed these enhancements shortly after the new attacks, and they have effectively addressed the problem for the time being. The RRL code works by keeping track of client requests, and for repeated requests for the same records from the same client addresses it rate limits the responses, either by silently ignoring some requests, or providing small 'truncated' responses. The working assumption is that well behaved DNS resolvers cache responses for the advertised TTL of the record and so should not be making repeated queries for the same record in a short period of time. The truncated responses when encountered will cause well behaved DNS resolvers to retry their query over TCP, which cannot be effectively used in forged address attacks. More details of how this works are available in this <a href="http://ss.vix.su/~vixie/isc-tn-2012-1.txt" target="_blank">technical note describing the operation of RRL</a>. I've heard that the RRL extensions are planned to be incorporated officially into <a href="https://www.isc.org/software/bind" target="_blank">BIND</a> 9.10, although from the recent announcement about ISC's new <a href="http://www.dns-co.com/solutions/bind/" target="_blank">DNSco subsidiary</a>, it isn't clear whether this feature will be available only to commercial customers.<br />
<br />
Any record that produces a large response can be effectively employed in these attacks. Most of the attacks to date though have been using the DNS resource record type 'ANY' (RR type 255). This query, when directed to an authoritative server's zone name, returns all records at the apex of the zone. With DNSSEC, you'll additionally get DNSKEY, RRSIG, and NSEC/NSEC3 records. To give an idea of the scale of the amplification, a DNSSEC-enabled "upenn.edu, ANY" query generates a response that is roughly 88 times as large as the request (a query of about 38 bytes, and a response of 3,344 bytes). The actual amplification ratio of the bits on the wire is less than this because we have to consider the encapsulating headers (L2, IP, and UDP). With Ethernet (14 bytes) and IPv4 (20 bytes) and UDP (8 bytes), a 38-byte DNS query occupys an 80-byte Ethernet frame. The 3,344 byte DNS response packet exceeds the Ethernet MTU and is fragmented into 3 ethernet frames, totalling 3,470 bytes. This yields an amplification ratio of about 40x, so in the absence of rate limiting countermeasures, a 1Mbps stream of query traffic (about 1,500 queries/second) would have produced a 40Mbps stream of traffic directed towards the victim.<br />
<br />
Even non-DNSSEC zones produce a quite substantial amplification though, and often it's easily sufficient for an effective attack. From discussion with a number of colleagues at other institutions, it's clear that non-DNSSEC sites have also been undergoing the same types of attacks and have had to deploy rate limiting countermeasures.<br />
<br />
Some people have proposed not answering requests for ANY (and after all ANY was only meant to be a diagnostic tool and not intended for production uses). This might buy time until attackers adapt to using other records. But it could cause collateral damage also. It turns out there is a variety of software that uses ANY for different purposes. For example, the <a href="https://www.powerdns.com/recursor.html" target="_blank">PowerDNS recursor</a> uses it to obtain A and AAAA records from authority servers in one query and response (normally two query/responses would be required).<br />
<br />
So, what can be done in the long term? The RRL implementations appear to be working very well at many sites, but attackers will undoubtedly adapt their methods - perhaps by performing more highly distributed attacks across many authoritative servers using a larger set of record types. Some folks at NLnet Labs have written a good paper that discusses some of the issues: <a href="http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf" target="_blank">Defending against DNS reflection amplification attacks</a>. Also, although RRL has been designed very carefully to minimize collateral damage, there will still be situations in which it might not work very well, eg. when dealing with resolvers behind large scale NATs and CGNs - a problem which might be increasingly common as we approach IPv4 depletion.<br />
<br />
There doesn't seem to be much hope (or incentive) for widescale deployment of BCP38 and other methods to reduce the scope of source address forgery. <br />
<br />
Ideas have also been proposed in the IETF to enhance the DNS query/response conversation with lightweight authentication cookies, which might thwart most forgery based attacks. See <a href="http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03">http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03</a> for example. But they would require widescale updates to a lot of DNS software to have an effect, and have thus far not gained much traction.<br />
<br />
Forcing DNS queries to use TCP is probably a much too heavyweight
solution that will impose large costs in terms of DNS response latency
and server resource requirements, although the experimental TCP cookie transactions extension (see
RFC 6013 - <a href="http://tools.ietf.org/html/rfc6013">http://tools.ietf.org/html/rfc6013</a> and this <a href="http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf" target="_blank">USENIX paper</a>) aims to address some of the issues. It may be necessary to consider a TCP based solution in light of some operational problems observed with UDP and large DNS packets - for example firewalls and other middle boxes that do not pass through IP fragments, or that botch up handling of extension mechanisms like EDNS0 that negotiate the use large UDP/DNS payloads.<br />
<br />
<h3 style="text-align: left;">
Response amplification survey at Internet2 schools </h3>
<br />
I was interested in knowing what size amplification the ANY query would produce at some other sites, so I wrote a quick program to do this and tabulate the results. I chose the set of 210 <a href="http://www.huque.com/app/dnsstat/category/internet2/" target="_blank">Internet2 universities that I already monitor at my dnsstat website</a>. For each zone, I ran an EDNS0 (DO=1) DNS query for ANY at the zone apex via each of the authoritative servers for the zone, and measured the query and response size and the resulting amplification (response_size/query_size). The <a href="http://www.huque.com/dns/measure/dns-amp-internet2.txt" target="_blank">full set of data can be seen here</a>, but I'll just excerpt some of the entries from the beginning of the file, sorted by descending order of response amplification. As expected the largest amplifications (in the neighborhood of 100x for DNS payloads, 50x for full packets) are all from DNSSEC signed zones. But many non DNSSEC zones produce large amplifications too. The very low amplification ratios for the zones towards the end of the dataset are mostly due to DNS servers that don't understand EDNS0 and return FORMERR (format erorr) responses.<br />
<br />
#########################################################################<br />
# DNS response amplification results for ANY query at zone apex.<br />
# Data collected 2013-04-10<br />
# Sorted by descending order of response amplification ratio (last column)<br />
# Amplification is the ratio of the DNS response and request payloads only,<br />
# it doesn't include the encapsulated UDP/IP/L2 etc headers.<br />
# Line Format:<br />
# zone ns_name ns_address query_size response_size amp1 amp2<br />
# amp1 is the ratio of DNS response payload to DNS query payload<br />
# amp2 is the estimated ratio of the entire response packet(s) to request <br />
# packets, assuming an ethernet path MTU.<br />
#########################################################################<br />
ksu.edu nic.kanren.net. 164.113.192.242 36.0 4085.0 113.47 53.99<br />
ksu.edu kic.kanren.net. 164.113.92.250 36.0 4085.0 113.47 53.99<br />
umbc.edu UMBC3.umbc.edu. 130.85.1.3 37.0 4093.0 110.62 53.41<br />
lsu.edu phloem.uoregon.edu. 128.223.32.35 36.0 4016.0 111.56 53.10<br />
lsu.edu bigdog.lsu.edu. 192.16.176.1 36.0 4016.0 111.56 53.10<br />
umbc.edu UMBC5.umbc.edu. 130.85.1.5 37.0 4045.0 109.32 52.80<br />
umbc.edu UMBC4.umbc.edu. 130.85.1.4 37.0 4045.0 109.32 52.80<br />
sdsmt.edu ns5.gratisdns.dk. 85.17.221.46 38.0 4095.0 107.76 52.76<br />
sdsmt.edu ns4.gratisdns.dk. 87.73.3.3 38.0 4095.0 107.76 52.76<br />
sdsmt.edu ns2.gratisdns.dk. 208.43.238.42 38.0 4095.0 107.76 52.76<br />
sdsmt.edu ns1.gratisdns.dk. 109.238.48.13 38.0 4095.0 107.76 52.76<br />
uiowa.edu dns3.uiowa.edu. 128.255.1.27 38.0 4093.0 107.71 52.74<br />
uiowa.edu dns2.uiowa.edu. 128.255.64.26 38.0 4093.0 107.71 52.74<br />
uiowa.edu dns1.uiowa.edu. 128.255.1.26 38.0 4093.0 107.71 52.74<br />
lsu.edu otc-dns2.lsu.edu. 130.39.254.30 36.0 3972.0 110.33 52.54<br />
lsu.edu otc-dns1.lsu.edu. 130.39.3.5 36.0 3972.0 110.33 52.54<br />
ucr.edu adns2.berkeley.edu. 128.32.136.14 36.0 3965.0 110.14 52.45<br />
ucr.edu adns1.berkeley.edu. 128.32.136.3 36.0 3965.0 110.14 52.45<br />
ualr.edu ns4.ualr.edu. 130.184.15.85 37.0 3979.0 107.54 51.96<br />
ualr.edu ns3.ualr.edu. 144.167.5.50 37.0 3979.0 107.54 51.96<br />
ualr.edu ns2.ualr.edu. 144.167.10.1 37.0 3979.0 107.54 51.96<br />
ualr.edu ns.ualr.edu. 144.167.10.48 37.0 3979.0 107.54 51.96<br />
uiowa.edu sns-pb.isc.org. 192.5.4.1 38.0 4013.0 105.61 51.74<br />
sdsmt.edu ns3.gratisdns.dk. 194.0.2.6 38.0 3963.0 104.29 51.11<br />
berkeley.edu ns.v6.berkeley.edu. 128.32.136.6 41.0 4040.0 98.54 50.19<br />
berkeley.edu adns2.berkeley.edu. 128.32.136.14 41.0 4040.0 98.54 50.19<br />
berkeley.edu adns1.berkeley.edu. 128.32.136.3 41.0 4040.0 98.54 50.19<br />
upenn.edu noc3.dccs.upenn.edu. 128.91.251.158 38.0 3866.0 101.74 49.90<br />
berkeley.edu sns-pb.isc.org. 192.5.4.1 41.0 3996.0 97.46 49.66<br />
berkeley.edu phloem.uoregon.edu. 128.223.32.35 41.0 3996.0 97.46 49.66<br />
ksu.edu ns-3.ksu.edu. 129.130.139.150 36.0 3651.0 101.42 48.42<br />
ksu.edu ns-2.ksu.edu. 129.130.139.151 36.0 3651.0 101.42 48.42<br />
ksu.edu ns-1.ksu.edu. 129.130.254.21 36.0 3651.0 101.42 48.42<br />
indiana.edu dns1.iu.edu. 134.68.220.8 40.0 3671.0 91.78 46.30<br />
indiana.edu dns1.illinois.edu. 130.126.2.100 40.0 3671.0 91.78 46.30<br />
indiana.edu dns2.iu.edu. 129.79.1.8 40.0 3655.0 91.38 46.11<br />
mst.edu dns02.srv.mst.edu. 131.151.245.19 36.0 3433.0 95.36 45.63<br />
okstate.edu ns2.cis.okstate.edu. 139.78.200.1 40.0 3599.0 89.97 45.43<br />
okstate.edu ns.cis.okstate.edu. 139.78.100.1 40.0 3599.0 89.97 45.43<br />
mst.edu ns-2.mst.edu. 131.151.247.41 36.0 3417.0 94.92 45.42<br />
mst.edu ns-1.mst.edu. 131.151.247.40 36.0 3417.0 94.92 45.42<br />
mst.edu dns01.srv.mst.edu. 131.151.245.18 36.0 3417.0 94.92 45.42<br />
mst.edu dns03.srv.mst.edu. 131.151.245.20 36.0 3385.0 94.03 45.01<br />
mst.edu ns1.umsl.com. 134.124.31.136 36.0 3369.0 93.58 44.81<br />
ucr.edu ns2.ucr.edu. 138.23.80.20 36.0 3356.0 93.22 44.64<br />
ucr.edu ns1.ucr.edu. 138.23.80.10 36.0 3356.0 93.22 44.64<br />
ksu.edu nic.kanren.net. 2001:49d0:2008:f000::5 36.0 4085.0 113.47 43.58<br />
ksu.edu kic.kanren.net. 2001:49d0:2003:f000::5 36.0 4085.0 113.47 43.58<br />
upenn.edu dns2.udel.edu. 128.175.13.17 38.0 3344.0 88.00 43.38<br />
upenn.edu dns1.udel.edu. 128.175.13.16 38.0 3344.0 88.00 43.38<br />
upenn.edu adns2.upenn.edu. 128.91.254.22 38.0 3344.0 88.00 43.38<br />
upenn.edu sns-pb.isc.org. 192.5.4.1 38.0 3312.0 87.16 42.98<br />
lsu.edu phloem.uoregon.edu. 2001:468:d01:20::80df:2023 36.0 4016.0 111.56 42.88<br />
lsu.edu bigdog.lsu.edu. 2620:105:b050::1 36.0 4016.0 111.56 42.88<br />
[ ... rest of data omitted ...]<br />
<br />
<a href="http://www.huque.com/dns/measure/dns-amp-internet2.txt" target="_blank">Link to full data set.</a> <br />
<br />
-- Shumon Huque</div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com7tag:blogger.com,1999:blog-8235843539067563488.post-76587543850206226262013-04-10T12:15:00.000-04:002013-04-10T12:15:41.093-04:00ISOC ION Panel: Advancing the Network<div dir="ltr" style="text-align: left;" trbidi="on">
<i>"I tend to think of IPv6 & DNSSEC both a little bit like global warming ... something that is developing kind of slowly ... they're both inevitable, it's a just a question of how long it's going to take"</i><br />
- Paul Mockapetris.<br />
<br />
The Internet Society has posted a video (1 hour 7 minutes) of the ISOC ION panel that I moderated on "Advancing the Network - Where We've Been, Where We're Headed" in San Diego on December 11th:<br />
<br />
<a href="http://www.internetsociety.org/deploy360/blog/2013/04/video-advancing-the-network-where-weve-been-where-were-headed-ion-san-diego/">http://www.internetsociety.org/deploy360/blog/2013/04/video-advancing-the-network-where-weve-been-where-were-headed-ion-san-diego/</a><br />
<br />
The panelists were Ron Broersma (DREN), Paul Ebersman (Infoblox), John Spence (nephos6), and Paul Mockapetris (Nominum; and inventor of the DNS), and the main topics of discussion were IPv6 and DNSSEC. All the presentations and the subsequent Q&A were quite informative and worth listening to.<br />
<br />
One correction I should make to something I said in my introductory remarks. My last slide showed some statistics from the SecSpider DNSSEC zone monitoring project. Since that project relies on user submissions and some amount of crawling, by now, it vastly underestimates the amount of DNSSEC deployment. There aggregate numbers are roughly 275,000 signed zones, whereas the actual number is a lot higher. The netherlands Top Level Domain (.NL) for example has more than 1.4 million signed zones underneath it:<br />
<br />
<a href="http://xs.powerdns.com/dnssec-nl-graph/">http://xs.powerdns.com/dnssec-nl-graph/</a><br />
<br />
--Shumon.<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com8tag:blogger.com,1999:blog-8235843539067563488.post-36658771869485689412013-03-26T18:45:00.000-04:002013-03-26T18:45:25.839-04:00IPv6 and DNSSEC at LOPSA-East Conference<div dir="ltr" style="text-align: left;" trbidi="on">
I'm teaching 1/2 day courses on IPv6 and DNSSEC at this year's <a href="http://lopsa-east.org/2013/" target="_blank">LOPSA-East conference</a> again, being held in New Brunswick, New Jersey, May 3rd-4th 2013.<br />
<br />
The <a href="http://lopsa-east.org/2013/lopsa-east-training/#sa1" target="_blank">IPv6 course</a> is an updated version of the one I did last year at <a href="http://lopsaeast.org/picc12/" target="_blank">PICC</a> (PICC has since been renamed LOPSA-East) and elsewhere.<br />
<br />
Last year I also did a combined course on DNS and DNSSEC. This year's <a href="http://lopsa-east.org/2013/lopsa-east-training/#sa4" target="_blank">course is focussed on DNSSEC</a> specifically. This will allow me to go into much more detail on how DNSSEC works, how to configure and deploy it (probably with live examples using BIND), etc. I'll also have more time to discuss <a href="http://blog.huque.com/2012/10/dnssec-and-certificates.html" target="_blank">DANE</a> and application uses of DNSSEC. <br />
<br />
Early bird registration discounts for the conference end April 1st. The full schedule of talks and training programs can be seen at:<br />
<br />
<a href="http://lopsa-east.org/2013/talks/">http://lopsa-east.org/2013/talks/</a><br />
<a href="http://lopsa-east.org/2013/lopsa-east-training/">http://lopsa-east.org/2013/lopsa-east-training/</a><br />
<br />
--Shumon Huque<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/04021419039454917129noreply@blogger.com17