Subject: [karp] Fwd: New Version Notification for draft-lebovitz-kmart-roadmap-03

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sun, 08 Nov 2009 20:49:56 -0800

Folks,
The window for I-D submissions opened today, so I uploaded ver -03, 
and it's now posted to the I-D repository. This is the same version 
that I sent to the email list last week.

Gregory.

>Delivered-To: [email-masked]
>Authentication-Results: mx.google.com; spf=neutral (google.com: 
>64.170.98.32 is neither permitted nor denied by best guess record 
>for domain of [email-masked]) smtp.mail=[email-masked]
>From: IETF I-D Submission Tool <[email-masked]>
>To: [email-masked]
>Subject: New Version Notification for draft-lebovitz-kmart-roadmap-03
>Date: Sun,  8 Nov 2009 20:45:24 -0800 (PST)
>
>
>A new version of I-D, draft-lebovitz-kmart-roadmap-03.txt has been 
>successfuly submitted by Gregory Lebovitz and posted to the IETF repository.
>
>Filename:       draft-lebovitz-kmart-roadmap
>Revision:       03
>Title:          Roadmap for Cryptographic Authentication of Routing 
>Protocol Packets on the Wire
>Creation_date:  2009-11-05
>WG ID:          Independent Submission
>Number_of_pages: 43
>
>Abstract:
>In the March of 2006 the IAB held a workshop on the topic of
>"Unwanted Internet Traffic".  The report from that workshop is
>documented in RFC 4948 [RFC4948].  Section 8.2 of RFC 4948 calls for
>"[t]ightening the security of the core routing infrastructure."  Four
>main steps were identified for improving the security of the routing
>infrastructure.  One of those steps was "securing the routing
>protocols' packets on the wire."  One mechanism for securing routing
>protocol packets on the wire is the use of per-packet cryptographic
>message authentication, providing both peer authentication and
>message integrity.  Many different routing protocols exist and they
>employ a range of different transport subsystems.  Therefore there
>must necessarily be various methods defined for applying
>cryptographic authentication to these varying protocols.  Many
>routing protocols already have some method for accomplishing
>cryptographic message authentication.  However, in many cases the
>existing methods are dated, vulnerable to attack, and/or employ
>cryptographic algorithms that have been deprecated.  This document
>creates a roadmap of protocol specification work for the use of
>modern cryptogrpahic mechanisms and algorithms for message
>authentication in routing protocols.  It also defines the framework
>for a key management protocol that may be used to create and manage
>session keys for message authentication and integrity.  This roadmap
>reflects the input of both the security area and routing area in
>order to form a jointly agreed upon and prioritized work list for the
>effort.
>
>Status of this Memo
>
>This Internet-Draft is submitted to IETF in full conformance with the
>provisions of BCP 78 and BCP 79.
>
>Internet-Drafts are working documents of the Internet Engineering
>Task Force (IETF), its areas, and its working groups.  Note that
>other groups may also distribute working documents as Internet-
>Drafts.
>Internet-Drafts are draft documents valid for a maximum of six months
>and may be updated, replaced, or obsoleted by other documents at any
>time.  It is inappropriate to use Internet-Drafts as reference
>material or to cite them other than as "work in progress."
>
>The list of current Internet-Drafts can be accessed at
>http://www.ietf.org/ietf/1id-abstracts.txt.
>
>The list of Internet-Draft Shadow Directories can be accessed at
>http://www.ietf.org/shadow.html.
>
>This Internet-Draft will expire on May 9, 2010.
>
>Copyright Notice
>
>Copyright (c) 2009 IETF Trust and the persons identified as the
>document authors.  All rights reserved.
>
>This document is subject to BCP 78 and the IETF Trust's Legal
>Provisions Relating to IETF Documents
>(http://trustee.ietf.org/license-info) in effect on the date of
>publication of this document.  Please review these documents
>carefully, as they describe your rights and restrictions with respect
>to this document.  Code Components extracted from this document must
>include Simplified BSD License text as described in Section 4.e of
>the Trust Legal Provisions and are provided without warranty as
>described in the BSD License.
> 
>
>
>
>The IETF Secretariat.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m