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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 14 February 2008 03:07 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 EBBD528C81B; Wed, 13 Feb 2008 19:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Level:
X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 Ht0L+u4N2kyK; Wed, 13 Feb 2008 19:07:00 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77E128C747; Wed, 13 Feb 2008 19:07:00 -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 59AB128C7CD for <rpsec@core3.amsl.com>; Wed, 13 Feb 2008 19:06:59 -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 Zk8T+giQBccR for <rpsec@core3.amsl.com>; Wed, 13 Feb 2008 19:06:54 -0800 (PST)
Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id DABC528C7BA for <rpsec@ietf.org>; Wed, 13 Feb 2008 19:06:53 -0800 (PST)
Received: by el-out-1112.google.com with SMTP id j27so319946elf.25 for <rpsec@ietf.org>; Wed, 13 Feb 2008 19:08:15 -0800 (PST)
Received: by 10.142.128.6 with SMTP id a6mr633754wfd.206.1202958494503; Wed, 13 Feb 2008 19:08:14 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Wed, 13 Feb 2008 19:08:14 -0800 (PST)
Message-ID: <77ead0ec0802131908y323f5ba8l3c84e9760f8699a6@mail.gmail.com>
Date: Wed, 13 Feb 2008 19:08:14 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Ron Bonica <rbonica@juniper.net>
In-Reply-To: <47B3173B.5090106@juniper.net>
MIME-Version: 1.0
Content-Disposition: inline
References: <6D26D1FE43A66F439F8109CDD42419650125AA3E@INEXC1U01.in.lucent.com> <47B3173B.5090106@juniper.net>
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

Thanks Ron.

Yes, I think TCP Auth is much better than current MD5 mechanism
defined currently. We certainly could refer it in our draft (as a
method to provide better security). It will be useful for LDP too
besides just BGP.

The OSPF part is good too. However our aim is to point out issues with
the protocol security mechanisms.

Thanks again,
Vishwas

On Feb 13, 2008 8:13 AM, Ron Bonica <rbonica@juniper.net> wrote:
> 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-existing-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
>
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
http://www.ietf.org/mailman/listinfo/rpsec