IETF 88 Part 1 - Guest Blog by Cathy Aronson

IETF 88 Part 1 - Guest Blog by Cathy Aronson [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

ARIN Advisory Council member, Cathy Aronson, is at IETF 88  in Vancouver, BC, Canada this week. Follow along as she shares her findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Cathy Aronson

Hi everyone.  This is my first blog post.  I am at IETF 88 in Vancouver.   This morning I attended the IEPG meeting.  So first a little bit of background.

IEPG is the Internet Engineering and Planning Group.  IEPG is an informal group that has been meeting before IETF meetings for the past 20 years.  The focus of the group is on operational matters on the Internet.  Sometimes there are a lot of presentations and sometimes there are only a couple.  There is a mailing list iepg@iepg.org and there is a document archive at iepg.org.

Today’s meeting was pretty interesting.  The first talk was about RPKI and Origin Validation deployment in Equador.  The LACNIC folks have been working on RPKI tools and deployment in their region.  A problem in the LACNIC region is that folks say they are not deploying RPKI because they have no experience with RPKI but in order to get experience they have to deploy RPKI.

In this deployment they turned up two route servers, one at each NAP.EC location.  These ran origin validation.  97% of all of Equador’s traffic goes through these exchanges.  This pretty much rolled out RPKI for that country.  This was an almost 10% increase in the uptake of RPKI for the LACNIC region.

As I presented at the ARIN meeting last month.  LACNIC is leading the way with RPKI tools  They have a tool that generates ROAs and also a looking glass that shows how an ORG’s routes are being announced.

RPKI and Origin Validation Deployment in Equador - Sofia Silva Berenguer, LACNIC

There was another interesting talk by Geoff Huston about whether folks are using Google’s public DNS.  They are using a google advertisement to get who it is that is querying and which resolver is being used.  7.2% used Google and 92.8% used others.  5.3% just use google and when it fails they don’t query anyone else.

The slides on who is using google are super interesting and I recommend that folks take a look.

http://www.potaroo.net/presentations/2013-11-03-googlepdns.pdf

Fernando Gont talked about fragmentation and extenstion header support in IPv6 Internet.  We know that service providers filter fragments but it turns out they filter extension headers too.  Someone from the audience mentioned that it is most likely firewalls that do this filtering.  More info can be found at www.ipv6hackers.org.

Fragmentation and Extension header Support in the IPv6 Internet - Fernando Gont

At the last ARIN meeting I talked about the DNS Hammer draft.  This is the draft that talks about how many hours folks spend clearing DNS caches and provides a mechanism to automatically refresh the cache instead of having someone manually do it all the time.  The Resolver Data Prefetch talk today is similar but in this case individual records are fetched when the timers (TTL) is going to expire.

The hammer draft is here:

http://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-00

The prefetch draft is here:

Resolver Data Prefetch - Wouter Wijngaards, NLnet Labs

“Making Special Better”  - Perl Liang from ICANN.

The special registry that the IANA maintains has gotten updated by the IANA.  The database no contains all special prefixes and what they are used for.  This will assist ISPs in generating the appropriate filters for these blocks.  This is nice work by the IANA and will help the community a lot.

Making Special better - Perl Liang, ICANN

Paul Vixie talked about security issues with DNS.   Paul asserts that there are problems with the DNS that the IETF should be solving.   I think it would be interesting for the IETF to take up these problems.  It does seem that DNSsec would solve most of the issues.  Maybe we should figure out why DNSsec isn’t more widely deployed?  Source address validation would also fix most of the problems but source address validation depends on the bad guys and they’re not going to do that.

On the Time Value of Security Features in DNS - Paul Vixie, Farsight Security

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.