Re: [karp] draft-ietf-karp-bfd-analysis-00 comments

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 09 May 2013 00:25 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ECA21F9104 for <karp@ietfa.amsl.com>; Wed, 8 May 2013 17:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtQtXEornlWH for <karp@ietfa.amsl.com>; Wed, 8 May 2013 17:25:37 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16321F8EAC for <karp@ietf.org>; Wed, 8 May 2013 17:25:37 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r490PZ9E004155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2013 19:25:35 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r490PZJZ011033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 May 2013 20:25:35 -0400
Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 8 May 2013 20:25:35 -0400
Received: from SG70XWXCHMBA01.zap.alcatel-lucent.com ([169.254.1.53]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 9 May 2013 08:25:32 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "karp@ietf.org" <karp@ietf.org>
Thread-Topic: [karp] draft-ietf-karp-bfd-analysis-00 comments
Thread-Index: AQHOTBUSVKEpC/kypkq1TZbgeL0yOZj7/X+w
Date: Thu, 9 May 2013 00:25:31 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C3014274@SG70XWXCHMBA01.zap.alcatel-lucent.com>
References: <20130508175410.GF12732@pfrc>
In-Reply-To: <20130508175410.GF12732@pfrc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.253.19.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [karp] draft-ietf-karp-bfd-analysis-00 comments
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2013 00:25:43 -0000

Hi Jeff,

Your analysis is correct - the gap analysis doc in the KARP lists the gaps that exists today when using manual keying. The two IDs that you've mentioned are still WG documents, and not yet standards and have been mentioned here in the gap analysis document. Additionally, I think we should also cover any new security considerations introduced by BFD over LAGs when using manual keying. I haven't thought much over this.

Cheers, Manav

> -----Original Message-----
> From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On 
> Behalf Of Jeffrey Haas
> Sent: Wednesday, May 08, 2013 11:24 PM
> To: karp@ietf.org
> Subject: [karp] draft-ietf-karp-bfd-analysis-00 comments
> 
> I've just read the current version of 
> draft-ietf-karp-bfd-analysis.  I have one comment and one question:
> 
> The draft correctly identifies the potential security 
> implications of predictable BFD session discriminator values. 
>  The following text in RFC 5880 attempts to cover this issue:
> 
> 
>    bfd.LocalDiscr
> 
>       The local discriminator for this BFD session, used to uniquely
>       identify it.  It MUST be unique across all BFD sessions on this
>       system, and nonzero.  It SHOULD be set to a random (but still
>       unique) value to improve security.  The value is 
> otherwise outside
>       the scope of this specification.
> 
> Obviously implementations may make choices that are problematic from a
> replay standpoint, but I don't believe there is anything to 
> really cover in
> a new BFD document.  Do the authors believe otherwise, or is 
> this primarily
> pointing out "you know better, don't do that!"
> 
> It should also be noted that we have two I-Ds as WG documents 
> that cover the
> other issues noted in this draft: draft-ietf-bfd-hmac-sha and
> draft-ietf-bfd-generic-crypto-auth.
> 
> Presuming my analysis of the above is correct (an admonition 
> to do the right
> thing), this document appears of reasonable quality.  Is 
> there an intent to
> last call it sometime soon?
> 
> -- Jeff
> _______________________________________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo/karp
>