%% You should probably cite rfc6862 instead of this I-D. @techreport{ietf-karp-threats-reqs-05, number = {draft-ietf-karp-threats-reqs-05}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/05/}, author = {Gregory M. Lebovitz and Manav Bhatia}, title = {{Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements}}, pagetotal = 32, year = 2012, month = may, day = 10, abstract = {Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security.}, }