Lightning talk Tuesday: DNS KSK must be replaced

Geoff Huston gave a lightning talk on Tues eve about the fact that the Key Signing Key for DNSSEC has reached end of lifetime (5 years) and needs to be replaced.

https://blog.apnic.net/2015/05/22/the-dns-root-zone-key-signing-key-is-changing/

Issues:

The problem is that a roll of the Root Zone KSK has never been done before. While there is a standard specification of how a resolver can update its local copy of the KSK (documented in RFC 5011) it’s not clear how many DNSSEC-validating resolvers support this standard. Those resolvers that don’t support RFC5011 will be left stranded with the old KSK value and will no longer operate as intended until an operator reloads the resolver with the new KSK value.

The key roll also involves a period of slightly larger responses from the Root Zone, of up to 1,425 octets. This should not present a major issue, but it is above the 1,232 octet maximum unfragmented DNS payload in IPv6, and there are some concerns relating to UDP fragmentation in IPv6 and the fallback to TCP that have yet to be quantified.

Given these unknowns, this roll of the KSK is going to need to be handled carefully for DNSSEC to continue to operate properly for the pool of 750 million users who already rely on it.

Motivation, Analysis, and Architecture for IPv4aaS

Motivation, Analysis, and Architecture for IPv4aaS - See more at: https://www.nanog.org/meetings/abstract?id=2572#sthash.nEGQdBEn.dpuf 

In this talk, we share our work in creating an “IPv4 as a service” network overlay. We begin by suggesting there is value in building network infrastructure which is “lean” and "IPv6 focused". There is likely value in focusing on a lean FIB infrastructure and IPv6 focused functionality in our next-generation routing platforms. We performed traffic analysis on how IPv4 is being used in our network today. We found that 90% of the traffic in our fully routed backbone is done by %0.005 of the routes. 99% of the traffic is performed by 4.5% of the prefixes. This data suggests we can incrementally deploy an IPv4aaS solution. Our goal is to build an IPv4aaS using cloud infrastructure based on open source and home grown software. We then present an IPv4aaS built on top of LISP. While we use LISP encapsulation, we have decided not to use the LISP DDT “routing” mechanism. Our IPv4aaS overlay routing architecture must associate IPv4 prefixes with IPv6 next-hops. This isn’t supported with “classic” BGP today. To solve this, we augmented JSON BGP IPv4 prefix updates with additional JSON information, namely an IPv6 next-hop. Effectively, we created a BGP IPv4 update with an IPv6 next-hop value. These messages are HTTP PUT to a route reflector / controller device, which processes the updates and applies associated business rules. These messages are then HTTP PUT to the overlay ingress (iTR) which announce a “default” to the underlay network. We then suggest the concepts in this presentation are an extension to the concepts we've made at the previous two June NANOG meetings.

 Discussion of IPv4 overlay on top of IPv6 over time. So wants to start thinking about how that should look like before it happens. Assumption is that the world moves to v6 and optimizes for v6 and then keeps v4 running somehow.

Concepts: Want to have a "lean core" to reduce costs for hardware, mgmt, etc. That means v6-only core as the endgame, so need to think about getting there over time.

575K prefixes in current FIB. Based on studies, 72 percent of prefixes being advertised are not being used. Only about 160K prefixes have traffic. 415K prefixes have no measurable traffic!

Comcast analysis: to carry 90 percent of v4 load need 3,156 prefixes. About 2,300 Comcast, 900 Internet.

Thinking about building overlay/underlay, looks like don't need that many prefixes for the v4 overlay.

99 percent point is 25,893 prefixes (from comcast view of world) - about 6K are comcast prefixes.
So 99 percent of Internet is carried on about 20K prefixes. Very interesting....

Use LISP to virtualize v4 delivery in the cloud. IPv4aaS as overlay in VMs on cloud infrastructure. LISP ETRs and ITRs close to customer ingress/egress. Overlay would be primarily outbound service.

Peering provider can identify which prefixes with significant load and forward via main hardware path. The rest are punted to LISP overlay. Heavy hitter prefixes routed on underlay. The rest carried over overlay.

"openstack isn't quite ready, still too data-center-centric and needs more work to get isolated from DC problem space and become more general for using in this model of overlay/underlay.

Control plane evolution to JSON and HTTP - (NANOG 2013 New Orleans - Applying Web principles to the network)

Open router platforms: (NANOG 2014 Bellevue - open router platforms)
Randy Bush: ask vendors for reduction of prefixes that is possible by de-duplicating information

QUIC: Next generation multiplexed transport over UDP

QUIC: Next generation multiplexed transport over UDP

See more at: https://www.nanog.org/meetings/abstract?id=2586#sthash.PMHBdN2A.dpuf

QUIC is a new transport protocol that runs on top of UDP. It is currently deployed to a significant fraction of Chrome users of Google services. It combines TCP-style congestion control, TLS-grade security, and HTTP/2 multiplexing. Our measurements on real-world traffic show that QUIC significantly decreases page load times and time between pauses in video playbacks. Google will continue scaling up the use of QUIC on the public internet over the next few months, with the goal of sending all Google traffic over QUIC. This talk will discuss how QUIC works, why it's an improvement over TCP, the problems we're anticipating as we deploy at scale, and what we're doing to prevent them. - See more at: https://www.nanog.org/meetings/abstract?id=2586#sthash.PMHBdN2A.dpuf  

New Google proto to replace TCP for Web access. Incorporates TCP Cubic, adds signaling improvements such as retransmissions have new sequence number. Improved congestion control.

Lots of things people want to add to TCP, but it's hard to do. Selective ack, SACK, took 20 years to get to 90 percent deployment in TCP.

QUIC uses port 443. QUIC combines handshake for connection with security and you can send request with first transaction in the first round trip. Lots faster than TCP. QUIC very comparable to TLS, always encrypted. zero RTT handshake. Plans to adopt TLS 1.3 when complete. Signed proof of address.

peering.google.com has QUIC info: https://peering.google.com/about/quicfaq.html

Zero RTT is the biggest single feature - over 50 percent better perf. Better loss recovery as well. 10x fewer timeout based retransmissions vs TCP.

2014: chrome stable, rollout started Jan 2015.
On client side, if UDP is blocked then fall back to HTTP/TCP.
If path MTU too small (QUIC uses 1350B packet) then falls bacl to TCP
There is a Chrome flag to disable

Google can disable QUIC on a per-ASN basis if needed. Don't want to do it, but sometimes have to because of degraded quality of experience reports in Youtibe (most common indicator).

Need to sign up for access to per-ASN QUIC info: https://peering.google.com/portalaccess/

There is a wireshark plugin for QUIC.
Chrome will display QUIC stats with: chrome://net-internals/#quic

Future: Forward error correction. - Experimenting with it, but hard.
Connection mobility - starting to work on that and multipath
Looking at improvements in congestion control. Kept TCP congestion control the same in QUIC for the moment.
Working to support in Apache Traffic Server
Google Chrome and some Google Android Apps are current main users of QUIC

QUIC was presented to IETF in 2013
Mar 2015: QUIC crypto was presented and has informed TLS 1.3 development and will subsume QUIC crypto as a profile in TLS 1.3
Working to move QUIC zero RTT handshale into TLS1.3 so can adopt TLS 1.3 into QUIC
QUIC is open source- all in Chromium source. No separate library so it's all in Chrome at this point.
QUIC designed to improve user experience, lower latency, faster response.

Q: constant encryption is a cost in CPU why choose to do so? A: have reduced CPU load and we (google) choose to encrypt everything.

Note: QUIC will fail at sites with firewalls blocking UDP. So the firewalled world is exacting yet another cost in latency and quality of experience (not that they care)

Rethinking Centralization

Rethinking Centralization

Centralization seems to be the current "silver bullet" for network complexity — but will it really "solve" for complexity, or just bring us another round of "pushing complexity around?" This presentation considers an alternative view of the centralization/decentralization debate. - See more at: https://www.nanog.org/meetings/abstract?id=2571#sthash.QlDGUQ1K.dpuf

Noticed over the years that we keep adding layers to try to manage complexity. But we  end up doing roughly the same things over and over again at each layer.

Why not lose all the layers and drop the whole mess into the control plane? Just layer the control plane. (VXLAN?)

Theory is that the control plane already has the best possible scalability protocols for reachability etc. - BGP, etc.

Where does it make sense to have an API vs a protocol?

Can polling ever outrun local reaction to an event? No. Local reaction is always faster.

Should policy be expressed in terms of forwarding?

Is a unified view of the network actually possible? We may be getting to the point of using heuristics vs algorithms.

What should be do about failure domains?

Are we ready to throw away 20+ years of experience to "try something new" (totally centralized -- his answer is "no")

Basically he is in favor of decentralization and not SDN.

Whither forward? Support YANG/NETCONF and I2RS
Think about existing protocols for southbound: BGP, PCEP

Has lived through "centralization vs decentralization" several times and thinks it is the wrong debate.

Dave Meyer: Is complexity always a bad thing. But if you want robustness, you need complexity. It is gratuitous complexity that you don't want. Try to understand what complexity is adding robustness and what isn't. Discussion about layering is on-target. Layering is one way to build the good type of complexity because it helps you to isolate and understand.

Control of complexity comes down to policy dispersion - who controls and where?

Dynamic Service Chaining for SDN/NFV

"The modern service provider and data center networks demand cloud delivery model for agile and cost-effective rollout of services for revenue generation. There are some proposals to incorporate service insertion in the emerging SDN and NFV environments. However, the current methods are sub-optimal, complex and inflexible in delivering automated end-to-end service delivery.

In a virtualized cloud environment, service delivery requires intelligence in the network for policy-based traffic handling and differentiated services. Dynamic service chaining is a fundamental component in building an on-demand and scalable model for policy enforcement. This session will cover following topics:

1. NFV & Service chaining use cases
2. Challenges with existing solutions
3. Opportunities with dynamic service chaining
4. Policy Enforcement model in SDN/NFV environment
5. Dynamic Service Chaining Architecture & Design considerations
6. Benefits of Dynamic Service Chaining"
See more at: https://www.nanog.org/meetings/abstract?id=2595#sthash.a7BOBUqX.dpuf

Network Automation and Programmability Abstraction Layer

Network Automation and Programmability Abstraction Layer with Multivendor support - See more at: https://www.nanog.org/meetings/abstract?id=2588#sthash.EurgXQJg.dpuf

"The Python library dubbed Napalm - short for Network Automation and Programmability Abstraction Layer with Multivendor support - helps interact with devices from various vendors though a unified set of commands. It currently supports Arista, Juniper, Cisco (IOS-XR) and FortiGate. It provides methods to replace or merge the configurations on the devices, view a diff, commit the changes, or roll them back. It also provides an Ansible plugin, which enables administrators to push configurations directly from Ansible playbooks. Napalm is open source and available on Github: https://github.com/spotify/napalm We will present more details about Napalm, how to use it and show in a demo how to instantaneously configure a set of multivendor devices."

Notes:
Based on Ansible server mgmt system.Requires the ability to run an ansible agent on the network device. Works on Juniper and Arista. Not on Cisco IOS or NX-OS.

Works on IOS-XR with python library - need to look at library and see what they did to make it work with XR and whether that could be adapted to IOS or NX-OS. https://github.com/fooelisa/pyiosxr/
Device must support atomic changes and provide a config change interface. Would need to write library to emulate that capability since not supported in IOS or NX-OS.

Changes are idempotent, logs for everything done. Can get diffs prior to commit. Ansible provides a sophisticated framework for changes, and napalm python scripts apply configs to JunOS and EoS boxes.

Latency IPv4 vs IPv6: Understanding the difference

During last years much attention was paid for process of deploying IPv6 in different regions. And with growing IPv6 adoption the requirements also grew up. Today we require not just working IPv6 but reliable IPv6. Of course this aim brings to our attention IPv6 network latency which we want to be comparable to IPv4 latency. First measurements gave community very interesting and promising results – for some networks IPv6 was faster than IPv4. But why IPv6 had less latency – there was no clear evidence. In my report I’m going to discuss reasons why in some cases IPv6 is faster than IPv4 and why it is slower in other ones. - See more at: https://www.nanog.org/meetings/abstract?id=2591#sthash.aLuWKSDh.dpuf

Tried to understand claims of faster IPv6 performance. Assumed that it must arise from different network paths. Found more paths in v4 vs v6.  "Comparing different graphs" (where "graph" means "set of network paths")

Decided to compare connectivity for v6 vs v4 hosts. Found v6 is a subgraph of v4, as expected. Found that most paths going through Hurricane Electric - connectivity of HE is better than anyone else in v6.

Question: Is HE Tier-1? Who is Tier-1? No one will explain who is a member of Tier-1 club.

So comparisons of v6 speed are comparisons of HE performance at this time.