Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being part of the group was fun as always and we had quite some interesting conversations with peers from the IPv6 community.
We could even contribute a bit to some discussions, with two talks. I gave one titled “Will It Be Routed? – On IPv6 Address Space Allocation & Assignment Approaches in Very Large Organizations” in the Address Policy Working Group session on Wednesday. This is the abstract:
“In the course of their IPv6 planning & preparation efforts many large enterprises in Europe have decided to become a “Local Internet Registry” (LIR) and hence to apply for an IPv6 address space ‘allocation’ from RIPE (as opposed to IPv6 address space ‘assignments’ from their network providers). While for most of them this is an obvious step, which usually can be performed with manageable effort, it frequently brings up subsequent questions which are not that easy to answer, namely along the lines of
– ‘What can we reasonably expect on the Internet routing level when it comes to using this address space for subsidiaries/parts of our network outside of Europe and potentially announcing prefixes from local break-outs or regional hubs?’
– ‘(When) Does it make sense to apply for an IPv6 address space allocation at/from other Regional Internet Registries (RIRs)? All of them or ‘the main ones’?’
– ‘If we opt for following the path of applying for allocations from several RIRs, what are the specifics/prerequisites/pitfalls of these procedures at the individual RIRs? What about initial/recurring effort & costs?'”
The slides can be found here and here’s the video. I will present on the topic, but with a slighly more enterprise-oriented tone & content at the IPv6 Business Conference in Zurich on June 18th.
On Thursday Chris and I presented together on “Practical Analysis of OS Behavior in Contradicting SLAAC/DHCPv6 Environments and Its Implications”. This is the abstract:
“In an IPv6 environment nodes can obtain their main IP configuration parameters either by using stateless (via SLAAC) or stateful (via DHCPv6) approaches. To this end, three flags are used in Router Advertisement (RA) messages, the A, M and O flags, which, however, are mostly advisory – no specific actions are standardised in case of conflicting information. A recent IETF I-D (draft-ietf-v6ops-dhcpv6-slaac-problem) showed that several Operating Systems behave differently in various scenarios. In this talk we will present the results of a number of additional tests we performed to advance the research on this topic one step further. Specifically, we created test scenarios where a) there are two different IPv6 routers at the same time on the same link which advertise conflicting RA information and b) recursive DNS information is also provided in RAs (implementing RFC 6106). Such conflicting cases can be created either unintentionally (e.g. by human error/misconfiguration) or even deliberately by attackers on the local link. Based on the results the operational as well as the network stability/security implications will be discussed per case. Finally we will discuss suggestions as for the prevention of such unpleasant cases.”
The slides can be found here and here’s the video. Furthermore we have covered the topic in another post (you can find a link to the whitepaper there, too).
Furthermore it should be noted that there’s an IETF draft on “DHCPv6/SLAAC Interaction Problems on Address Auto-configuration” whose authors undertake the huge and very important task of structuring and classifying the problem space.
After the talk in the Address Policy WG session there was the recurring debate on strict prefix filtering and how it (badly) interacts with the needs of enterprises. I had given a talk on this in the Routing Working Group session at RIPE69 in London which was later updated for the Troopers IPv6 Security Summit. For those interested in this topic: the slides with the latest research results can be found here and my buddy Roland Langner authored an extensive publication with even more data which can be found here.
Furthermore, at many occasions, there were debates as for IPv6 extension headers. Please allow to quickly recap our position on those here:
– it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.
– we’re hence quite sceptical as for the “we might see cool use cases in 15-20 yrs” position someone expressed at the mic.
– from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case.
– looking at the “liberty” RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered this thesis. one can probably find much more issues provided time & resources).
Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn’t have a use case.
– the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown).
– now that “this vicious circle” has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.
===
On the first two days there were (mostly) the usual plenary sessions. From my perspective these presentations were particularly enlightening:
a) Ivan Pepelnjak on “Software Defined Networks Four Years Later”. The slides to be found here, the video here.
b) Bendert Zevenbergen from the Oxford Internet Institute on “Internet Engineering Meets Philosophy: Establishing Ethical Guidelines for Networked Systems Research”. Slides here, video here.
I consider this discussion as needed for a long time in our community. He’s one of the organizers of the upcoming “Workshop on Ethics in Networked Systems Research“, too.
===
Have a great Sunday everybody
Enno