Re: [RPSEC] Issues with existing Cryptographic Protection Methods for Routing Protocols

"Bhatia, Manav \(Manav\)" <manav@alcatel-lucent.com> Thu, 14 February 2008 02:08 UTC

Return-Path: <rpsec-bounces@ietf.org>
X-Original-To: ietfarch-rpsec-archive@core3.amsl.com
Delivered-To: ietfarch-rpsec-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3379B28C850; Wed, 13 Feb 2008 18:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.454
X-Spam-Level:
X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEjKSybkfKnZ; Wed, 13 Feb 2008 18:07:59 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2D23A6F65; Wed, 13 Feb 2008 18:07:59 -0800 (PST)
X-Original-To: rpsec@core3.amsl.com
Delivered-To: rpsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B95B28C519 for <rpsec@core3.amsl.com>; Wed, 13 Feb 2008 18:07:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po3FXqgUiqQm for <rpsec@core3.amsl.com>; Wed, 13 Feb 2008 18:07:56 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3EC763A6C8F for <rpsec@ietf.org>; Wed, 13 Feb 2008 18:07:56 -0800 (PST)
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m1E295Fq008260; Wed, 13 Feb 2008 20:09:14 -0600 (CST)
Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 20:09:01 -0600
Received: from INEXC1U01.in.lucent.com ([135.254.223.20]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 07:38:55 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 14 Feb 2008 07:38:52 +0530
Message-ID: <6D26D1FE43A66F439F8109CDD42419650125ADD6@INEXC1U01.in.lucent.com>
In-Reply-To: <47B3173B.5090106@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RPSEC] Issues with existing Cryptographic Protection Methods for Routing Protocols
Thread-Index: AchuW8/NrqUWfazKQzyC2TnYYJnyGgAUkyZw
References: <6D26D1FE43A66F439F8109CDD42419650125AA3E@INEXC1U01.in.lucent.com> <47B3173B.5090106@juniper.net>
From: "Bhatia, Manav (Manav)" <manav@alcatel-lucent.com>
To: Ron Bonica <rbonica@juniper.net>
X-OriginalArrivalTime: 14 Feb 2008 02:08:55.0252 (UTC) FILETIME=[8D358940:01C86EAE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Issues with existing Cryptographic Protection Methods for Routing Protocols
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rpsec-bounces@ietf.org
Errors-To: rpsec-bounces@ietf.org

Yes, I think it would be good to consider draft-ietf-tcpm-tcp-auth-opt
wrt BGP. We'll do this in the next cut.

Manav

> -----Original Message-----
> From: Ron Bonica [mailto:rbonica@juniper.net] 
> Sent: Wednesday, February 13, 2008 9.44 PM
> To: Bhatia, Manav (Manav)
> Cc: rpsec@ietf.org
> Subject: Re: [RPSEC] Issues with existing Cryptographic 
> Protection Methods for Routing Protocols
> 
> Guys,
> 
> This is a good summary. Thank you for writing it.
> 
> Do you think that it would be helpful to mention that some protocols
> (e.g., OSPFv2) have mechanisms for graceful rekeying.
> 
> Also, do you think that it might be helpful to consider
> draft-ietf-tcpm-tcp-auth-opt wrt BGP?
> 
>                                         Ron
> 
> 
> Bhatia, Manav (Manav) wrote:
> > Folks,
> > 
> > We have posted a revised version of the above draft. Would 
> appreciate
> > feedback from the WG.
> > 
> > Routing protocols are designed to use cryptographic mechanisms to
> > authenticate data being received from a neighboring router to ensure
> > that it has not been modified in transit, and actually 
> originated from
> > the neighboring router purporting to have originating the 
> data. Most of
> > the cryptographic mechanisms defined to date rely on hash algorithms
> > applied to the data in the routing protocol packet, which 
> means the data
> > is transported, in the clear, along with a signature based 
> on the data
> > itself.  These mechanisms rely on the manual configuration 
> of the keys
> > used to seed, or build, these hash based signatures.  This document
> > outlines some of the problems with manual keying of these 
> cryptographic
> > algorithms.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-manral-rpsec-existin
> g-crypto-0
> > 5.txt
> > 
> > Thanks,
> > Vishwas, Russ and Manav
> > _______________________________________________
> > RPSEC mailing list
> > RPSEC@ietf.org
> > http://www.ietf.org/mailman/listinfo/rpsec
> > 
> 
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
http://www.ietf.org/mailman/listinfo/rpsec