IEPG meeting notes by Geoff Huston Agenda: 1. IANA DNSSEC systems development - Richard Lamb 2. ULA-C - Paul Vixie 3. Network weather map - Simon Leinen 4. Trying to live in a dual-stack world - Simon Leinen 5. Flow performance parameters and what you can learn about inter-as traffic - Uninett 5. RIR update - Ray Plzak 6. IPv6 transition - Randy Bush 7. IPv4 Exhaustion, Jordi Palet 8. Resolver stats - Rodney Joffe Notes: DNSSEC deployment at IANA ------------------------- The approach to DNSSEC is a number of discrete components tied together to support DNSSEC includung the Key generator and HSM, the zone signer, the zone generator and then the publication process. Each element is constructed from basic off-the-self components. The key generator is off-line, in a conventional fashion using flash drive at this stage The zonesigner is auto run on multiple systems to pick up changed zones (SOA) or refreshed sigs and reload zonegen, signs the files and places in back on the zone generator system - also updates web pages and emits mail notifications The keygen is a monthly script for a new ZSK using a script on the HSM that generates new keys. pkcs#11 is used in these scripts. The potential problems with this approach are perceived to be operational in nature. IANA are committed to make the sources of this system public. IANA approach is 3 overlapping keys in ZSK with one active signed and KSK is 2 overlapping keys. Both KSKs sign the bundle of 3 ZSKs. There is an approach for emergency key rollover as a procedure with scripting support. The idea is that the emergency approach is to head to a new already ‘socialized' key. The hardware is a AEP keyper Pro (FIPS 140.2 Level 4) external HSM). Status page: https://ns.iana.org/dnssec/status.html Questions: Nominet has experience with HSMs and PCKS#11 calls from a BIND signers. OpenSSL has a library called “EVP” that allows an engine to be configured in. Has this approach been evaluated in the IANA context? There is a presentation from Nominet on HSMS and signing experience later in the IETF week. Nominet also uses incremental updates so there is a continual need for access to the private ZSK rather than periodic off-line access. There is an issue of the interplay between TTL and signature lifetime. There is a timing problem with sig expiration of already cached keys - ie is there TTL adjustment or deliberate use of signatures that exceed the TTL? The .se approach is to have 3 ZSKs and pre-publishing to alleviate this caching issue. Thereby you always have this other valid sitting in the background. ULA-C ----- [no slides] Reference to ULA work previously in IPv6 WG. Paul Vixie represented the motivation for ULA-C as being access to the reverse DNS zone [my note - this is not an accurate representation of the motivation of ULA-C, it's a potential byproduct of the uniqueness properties of ULA-Cs]. Paul has proposed a changed version of ULA-C's that has RIR-numbered ULA address blocks. Questions: ULA-C and the need for explicit bits to denote RIR. What is the interplay between PA/PI and ULA-C - has been any demonstrated case that could not be met with PI/PA? Evidently none so far, although a later comment noted that ULA-L is already in use. Network weather map ------------------- Looking at visualization efforts to overlay network operational status with maps of various forms. Google maps has an interface that permits arbitrary overlays and in this case there is a java application that performs dynamic network discovery and then generates overlay data for google maps. Trying to live in a dual-stack world ------------------------------------ Enterprise perspective of a Research Network in Switzerland (SWITCH). They have had extensive experience of IPv6. Most of the EU Research networks are dual-stacked on their backbones at this stage, but with continuing very small customer update of the IPv6 service. There is a steady effort in dual-stacking servers and related service delivery. Commented that a lot of the IPv6 traffic statistics are NNTP-related! There remain firewall / filter issues, and they are looking at a stopgap solution that generates equivalent local IPv6 rules from local IPv4 filters and DNS information. Extending IPFIX protocol for better QoS monitoring -------------------------------------------------- Uses passive monitoring hardware the extended IPFIX flow records with statistics for intensity, intervals and sizes in order to research delivered QoS. NRO Report ---------- [no notes] IPv4 Depletion and Migration to IPv6 ------------------------------------ Note that IPv4 space is diminishing and there are projections that point to 2010 / 2012 as being the time that we anticipate depletion of further available addresses in IPv4. BUT - noted that demand for IPv4 continues and IPv6 migration is "No to Slow". However exhaustion of the Ipv4 pool is inevitable and this presentation sees the migration to IPv6 as inevitable. Some RIRs have issued "advisory" notices, and created educational material as part of outreach. There is the activity in facilitating IPv6 deployment in industry, policy and administrative actions are underway in the RIRs, and implementing Ipv6-accessible services. ARIN is also being active in evaluation on IPv4 resource requests to undertake a conversation with the application over IPv6. Question: would the NRO aggregate the various RIR activities in a single web resource? IPv6 Transition and Operational Reality ---------------------------------------- Noted that there is no transition plan, and an early declaration of "victory" in IPv6. It is not a case of IPv4 "running out" - it's the unallocated address pool that is exhausting. Ipv4 will go to a trading model with eBay, with the RIRs taking up the role of to title agents. There is work in certification that can support trading mechanisms to some extent. IPv6 transition is not easy - its on-the-wire incompatible with Ipv4 - perhaps this could've been avoidable, but that's now in the past. There are no transition mechanisms. An IPv6 host cannot reach an IPv4 hosts without IPv4 addresses, and NATS and ALGs are inevitable here to perform IPv4 / IPv6 - the NATS are a reality in the dual stack world. There is no change in the multi-homing and TE models in IPv6, and the routing table dynamics are unaltered. The issues about of routing economics (or the lack thereof) remain unaltered. The presentation covered a number of issues that illustrate that IPv6 falls short in terms of some of the IPv6 hyperbole. http://www.civil-tongue.net/clusterf/ Comment: Large scale network transition takes considerable time. There is a certain amount of lock-stepping here, for example home gateway vendors want to wait for service deployment, but service deployment is waiting for edge capability and demand, etc. IPv4 Exhaustion ------------------- [no notes] Resolver Stats ---------------- Open Recursive Resolvers have been used as an attack springboard for over a year now as a means of DNS amplification. What's the open recursive resolver count today? This reports on an all-internet probe with continuous monitoring and analysis. An A query has been sent to all advertised addresses - there are 16.7 M open recursive resolvers! These 16M forwarded the query to some 800,000 unique resolvers i.e. this issue of open recursive resolvers is not being fixed! The forwarders are often CPE devices ( home gateways e.g. vigor 2600 with config setup by default to allow recursion on both sides) and manufacturers are part of the issue here. Work in DNS-OARC to analyse this further.