Subject: KARP WG Formed

From: Adrian Farrel <[email-masked]>
Date: Thu, 25 Feb 2010 13:06:37 +0000

Hi and heads-up.

Thanks to Brian and Joel for agreeing to chair this.

Looking forward to some constructive progress.

Adrian
----- Original Message ----- 
From: "IESG Secretary" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 23, 2010 9:00 PM
Subject: WG Action: Keying and Authentication for Routing Protocols (karp) 

>A new IETF working group has been formed in the Routing Area.  For
> additional information, please contact the Area Directors or the WG
> Chairs.
> 
> Keying and Authentication for Routing Protocols (karp)
> -------------------------------------------
> 
> Current Status: Active Working Group
> 
> Last Modified: 2010-02-23 
> 
> Additional information is available at tools.ietf.org/wg/karp 
> 
> Chair(s):
> Brian Weis <[email-masked]> 
> Joel Halpern <[email-masked]> 
> 
> Routing Area Director(s):
> Ross Callon <[email-masked]> 
> Adrian Farrel <[email-masked]> 
> 
> Routing Area Advisor:
> Ross Callon <[email-masked]> 
> 
> Technical Advisor(s):
> Tim Polk <[email-masked]> 
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/karp
> Archive: http://www.ietf.org/mail-archive/web/karp/current/maillist.html
> 
> Description of 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 described
> below.
> 
> - 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
> be required.
> 
> 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.
> 
> Work Items:
> 
> - 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
> protocols.
> 
> - 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.
> 
> Goals and Milestones:
> 
> Nov 2010 - Submit General Framework, General Requirements, and
> Priorities/Work-Plan documents to the IESG to be considered as
> Informational RFC
> 
> 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
> 
> Dec 2010 - Submit a document describing best practices for creating and
> using protocol message authentication integrity keys as a BCP
> 
> Apr 2011 - Submit specification document for OSPFv2 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
> 
> Jul 2011 - Submit specification document for OSPFv3 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
> 
> Oct 2011 - Submit specification document for PIM to the IESG to be
> considered as a Proposed Standard
> 
> Oct 2011 - Submit specification document for RSVP-TE to the IESG to be
> considered as a Proposed Standard
> 
> Nov 2011 - Specify automated key management needs for routing
> protocols using unicast techniques
> 
> Jan 2012 - Submit specification document for ISIS 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
> 
> Apr 2012 - Submit specification document for MSDP 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 BFD to the IESG to be
> considered as a Proposed Standard
> 
> Jul 2012 - Submit specification document for LMP to the IESG to be
> considered as a Proposed Standard
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>