RFC7985: We Like Breaking Stuff…

There are few things as fun as “breaking stuff”. Of course, not in the “temper-tantrum throwing toys around” way of an over-stimulated 4-years-old with a sugar-high from trick-or-treat Halloween-candy (belated happy Halloween btw., to those on the other side of the pond celebrating such) – but, in the  “figuring out weaknesses in a protocol, and developing exploits”  intellectual/adult sorta way.

Understanding how to “break stuff” is a great first step at understanding how to “build stuff that is hard to break” – and, consequently is a great pedagogical tool. At École Polytechnique, a course I teach in ‘breaking stuff’ in the 2nd year is actually the first step in acquiring solid “Cybersecurity” competencies: teaching how to, and have students hand-build tools to, hi-jack TCP connections, take down switches, do DNS poisoning, etc. serves not only to keep our IT support people and our CIO awake at night make students learn fairly intricate details about protocols, and have them write low-level code – but, more importantly of course: to get into the habit of when designing protocols and IT systems think “wait, how would someone go about breaking/hacking this?”. 

The operative word combination here is “…when designing…” – not “afterwards”: (cyber)security is not something to be bolted on post-factum, but is an integral part of the design process. When I, Christopher Dearlove, Ulrich Herberg, and Philippe Jacquet, designed OLSRv2, one of the things Christopher introduced was for each protocol data structure, to define constraints: which changes were, and were not acceptable (with proper protocol functioning in mind) – constraints that a conscious implementation would make sure to check, and use to reject received control messages whose processing would incur constraint violations.

Regardless, though, every protocol deserves a critical analysis and identification of vulnerabilities. And that is precisely what the just released RFC7985 is with regards to “RFC6621: Simplified Multicast Forwarding“: a critical study of the SMF protocol, emphasizing different ways in which it is possible for a third-party to disrupt proper network operations. For example, SMF introduces an additional component to the multicast forwarding path in a router (duplicate packet detection) – and, in general, every component added to a system  adds another attack surface – something among that which RFC7985 calls out and attempts to analyze.

%d bloggers like this: