Keying and Authentication for Routing Protocols (karp) Concluded WG
Note: The data for concluded WGs is occasionally incorrect.
|WG||Name||Keying and Authentication for Routing Protocols|
|Area||Routing Area (rtg)||State||Concluded|
|Dependencies||Document dependency graph (SVG)|
Charter for Working Group
The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection. At present, this charter explicitly excludes
confidentiality and non-repudiation concerns.
Authenticating the routing peer sending a message, and message integrity
protection, will be provided through the use of per-packet cryptographic
message authentication. Peer authentication will protect against
unrecognized peers, imposter peers, and some DoS attacks aimed at
routers. Protecting against misbehavior of an otherwise allowed peer
router is outside the scope of this working group.
Many routing protocols (or groups of protocols) already have some
method for accomplishing cryptographic message authentication.
In many or most cases existing methods are vulnerable to known
attack, and some employ cryptographic algorithms that have been
deprecated. While much work has been done to update authentication
of routing protocols, current status is not consistently up to date.
It is important to review and update those mechanisms to use modern
security practices. Ensuring algorithm agility within routing
protocols is of particular importance.
A goal of the working group is to add incremental security
to existing mechanisms rather than replacing them. Better deployable
solutions to which vendors and operators can migrate is more important
than getting a perfect security solution.
Although there are many candidate routing protocols to evaluate, KARP
must by necessity begin with a restricted focus. The initial set of
routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP,
RSVP-TE, ISIS, BFD, LMP, and MSDP.
The working group must coordinate very closely with other working
groups, such as:
- Routing protocol working groups for any routing protocol being
evaluated. This coordination will include cooperatively determining the
current or already planned state of the security work in the protocol.
It will also include ensuring that any proposed mechanisms are
consistent with the architecture and use of the protocol. Also, any
specific proposal accepted as a KARP document will be developed in
cooperation with the concerned protocol working group.
- Security area working groups for cryptographic advice, and/or key
management protocol support. Cryptographic protocol support may be
required in order to support certain KARP WG milestones. Coordination
with an appropriate working group in the security area would be
necessary in order to get the appropriate expertise in completing a
milestone. This charter provides for preliminary work in this space,
although it is expected that detailed work items will be added to the
charter when the problem has been better analyzed. For example, this may
include a key management protocol by which routing protcols
automatically negotiate keying material and policy. More about the use
of a key management protocol will be captured in a framework document
- OPSEC working group for advice on best practices to create and use
integrity keys used with routing protocol message authentication. KARP
will also coordinate with other Operations and Management area WGs
and/or experts in order to identify operational impacts on existing
routing protocols and to identify any management extensions that may
Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols. In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.
- Determine current threats to the routing protocol operation, and
define general requirements for cryptographic authentication of routing
protocols. A primary source for this document should be
draft-lebovitz-karp-roadmap, although RFC 4393 may also be useful.
- Identify deficiencies of each routing protocol in scope, and specify
mechanisms that bring them in line with the general requirements. These
are referred to as protocol gap analysis documents.
- Define one or more frameworks describing the common elements for
modern authentication in routing protocols.
- Publish guidance on how to create a gap analysis for routing
- Publish guidance on guidance to operators on how to create and use
integrity keys used with routing protocol message authentication.
- Specify automated key management needs for routing protocols.
|Jul 2012||Submit specification document for LMP to the IESG to be considered as a Proposed Standard|
|Apr 2012||Submit specification document for BFD to the IESG to be considered as a Proposed Standard|
|Apr 2012||Specify automated key management needs for routing protocols using multicast techniques|
|Apr 2012||Submit specification document for MSDP to the IESG to be considered as a Proposed Standard|
|Jan 2012||Submit specification document for PCE to the IESG to be considered as a Proposed Standard|
|Jan 2012||Submit specification document for ISIS to the IESG to be considered as a Proposed Standard|
|Nov 2011||Specify automated key management needs for routing protocols using unicast techniques|
|Oct 2011||Submit specification document for RSVP-TE to the IESG to be considered as a Proposed Standard|
|Oct 2011||Submit specification document for PIM to the IESG to be considered as a Proposed Standard|
|Jul 2011||Submit specification document for LDP to the IESG to be considered as a Proposed Standard|
|Jul 2011||Submit specification document for OSPFv3 to the IESG to be considered as a Proposed Standard|
|Apr 2011||Submit specification document for BGP to the IESG to be considered as a Proposed Standard|
|Apr 2011||Submit specification document for OSPFv2 to the IESG to be considered as a Proposed Standard|
|Dec 2010||ubmit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP|
|Nov 2010||Submit a framework document describing protocol groups and the common techniques and interfaces that apply to them to the IESG to be considered as Informational RFC|
|Nov 2010||Submit General Framework, General Requirements, and Priorities/Work-Plan documents to the IESG to be considered as Informational RFC|