On 12/30/15 9:16 PM, Patrik Fältström wrote: > Jari, > > Thank you for the blog post, and of course as co-chair of the ICG > working on the IANA Transition I fully support and want to emphasize > your last bullet, that we need to finalize the IANA transition, finally. > > But, I want to mention one detail you might have hidden in one of your > other bullets, although not explicitly, and that is one we in the > Security and Stability Advisory Committee of ICANN where I am chair have > been struggling with for years, and that is source address validation > (for IP addresses that is). In the IETF there is the well known BCP-38 > that for various reasons is questioned, although "implement BCP-38" is a > statement used for "do whatever is needed". In SSAC we already in 2004 > created SAC-004 > <https://www.icann.org/en/system/files/files/sac-004-en.pdf> about > "Securing the Edge". The main author of SAC-004, Paul Vixie, and others > have after that written numerous other documents on the same topic. Strict URPF filtering relied on to two convenient fictions: One that the forward and reverse path, both, carry the route for the originating prefix. Cases where where this is not the case are both ubiquitous and totally normal. Two that URPF is simple to implement in hardware, scales well on all architectures, and has little cost with respect to forwarding. Simply put it does not. While we might choose to restrict our definition of edge filtering to the single-homed customers of retail ISPs, there are rather a lot of those. There is on the other hand a plurality of transit ISPs that cannot implement BCP 38 as envisioned or even something close to it. > Baseline is, we must do something about it. For some definition of "we" > and some definition of "something". > > This is of course related to what Fred Baker brought up, that we do have > some tools, but they are not deployed. And if they are deployed, they > are not deployed to the degree and quality needed to give the intended > effect. > > We do have internationalized email addresses, we do have DNSSEC, we do > have IPv6, we do have...but how much of this is deployed? > > I am sorry to say I see even here on this list many people not using > technologies they argue about. If I take things I have some clue about, > I think, DNS, and check the domain names used for the conversation, > neither DNSSEC, nor IPv6 or any other by the IETF after RFC1035 invented > technology that is DNS related is in use. By the very same engineers > discussing how to move standards forward. Is that a sign, or at least > indication? > > Back to the source address validation issues. That the edge can source > IP packets with fake source IP addresses is a problem. It is, I claim, > the by far largest problem we have today. > > Is this connected to the fact that not even people developing standards > use very same standards? > > Has the IETF ended up being too academic and lost connection to what is > actually deployed? > > Sure, this gap between what is developed in the IETF and what is > deployed has always existed. Existed when I started be wg chair, > continued when I was an AD, continued even more when I was on IAB, and > later ISOC BoT, and now SSAC Chair. And some of the RFCs I have written > has been excellent examples of standards never taking off(!). > > So yes, I blame myself for not having answers to my own questions. If I > had, I would have pushed for the answers. I have at least myself > working(?) PGP, DNSSEC, IPv6, NAPTR and many other things. I.e. I am, I > claim, eating my own dog food. > > But, is the taste of our own food so bad we do not eat it ourselves? > > If so, how can we make others eat it? > > At least some flavor of BCP-38? > > Because that is really really the largest issue we have today. > > With this, all the best for a successful 2016! > > Patrik Fältström >
Attachment:
signature.asc
Description: OpenPGP digital signature