Re: [RPSEC] [OSPF] [sidr] Authentication for OSPFv3

"Vishwas Manral" <vishwas.ietf@gmail.com> Wed, 01 October 2008 01:19 UTC

Return-Path: <rpsec-bounces@ietf.org>
X-Original-To: rpsec-archive@megatron.ietf.org
Delivered-To: ietfarch-rpsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBD328C188; Tue, 30 Sep 2008 18:19:06 -0700 (PDT)
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 4D8C73A68BC for <rpsec@core3.amsl.com>; Tue, 30 Sep 2008 18:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.242
X-Spam-Level:
X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599]
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 u2lgRi0LSM9V for <rpsec@core3.amsl.com>; Tue, 30 Sep 2008 18:19:04 -0700 (PDT)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 34C643A6A08 for <rpsec@ietf.org>; Tue, 30 Sep 2008 18:19:04 -0700 (PDT)
Received: by fk-out-0910.google.com with SMTP id 18so2421429fkq.5 for <rpsec@ietf.org>; Tue, 30 Sep 2008 18:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oBHIb6NU7PoAIeI4H6P3dD/YO6iJgJJvlNejFvBvy8k=; b=t7jDOPrZOQ2BBMKBy9WwFjXYGrRbTLx+6bAnVJaoiUtCl4zSG8PQpW8oF5lv2K31wv dgbOeuP5vaDoiIQQwRmw/kWbPlyCNDwvmwZxctM7RaSTZpKC8nrK6QBfzULRMF/6Cqym zZz7tPVwUcx7jVMc4CNZfx0MNXxUYyKvfR4Gc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iCo3TL3OarxKQMFnFvEepNIyt1HJtKmtQpUGUbVzjVoNq21FJ6n5PM+RgtQYS8n4ck ZJJX16FqoiIHFM63yvTrBaZl1MpCviWWHmtFmR4OkSEqLxL0EmuAUZJolqe1be2aGaz8 //SheirBKyzsjKflrH59Ay6AB4MjwTkXyahxQ=
Received: by 10.181.2.2 with SMTP id e2mr3654366bki.3.1222823964541; Tue, 30 Sep 2008 18:19:24 -0700 (PDT)
Received: by 10.180.226.2 with HTTP; Tue, 30 Sep 2008 18:19:24 -0700 (PDT)
Message-ID: <77ead0ec0809301819q414bc6f3gfe8d0211118c6c30@mail.gmail.com>
Date: Wed, 01 Oct 2008 06:49:24 +0530
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sandy Murphy <sandy@tislabs.com>
In-Reply-To: <20080930162823.C92963F446@pecan.tislabs.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <77ead0ec0809300842i200798d5ic45f7996a19d57d@mail.gmail.com> <20080930162823.C92963F446@pecan.tislabs.com>
Cc: rpsec@ietf.org, acee@redback.com, ospf@ietf.org, sidr@ietf.org, rcallon@juniper.net
Subject: Re: [RPSEC] [OSPF] [sidr] Authentication for OSPFv3
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://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: <https://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

Hi Sandy,

The idea is that I am trying to state is the use of authentication at
2 levels (in BTNS they skip the authentication at the IKE exchange
altogather - and do it at a different layer if possible). At the first
level we use GTSM as the first filter for IKE itself and once the
system adjacencies are up we actually can use the full authentication/
any other form of authentication (so that reachability information is
there).

By doing this we may trust a peer entity but only for sometime, when
the adjacencies come up we have the option of doing a full
authentication. Regarding the issues with the way things work
currently (which will be mitigated) you can always look at the draft I
have written.

Thanks,
Vishwas

On 9/30/08, Sandy Murphy <sandy@tislabs.com> wrote:
>>I agree to what you say and the general sense of the room in the KMART BOF.
>>That is the reason I proposed a BTNS based solution. Which uses GTSM
>>in the IKe to do the first level security.
>
> I am not quite sure I understand the use of GTSM here.  The need for
> authentication for OSPF is that you don't trust that everyone on the
> local broadcast link is OK.  GTSM tells you that the sender came from
> one-hop away, i.e., on the local broadcast link.  Since you already know
> that you don't trust everyone one-hop away, how does the use of GTSM
> help?
>
> --Sandy
>
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/rpsec