Re: [OSPF] Authentication/Confidentiality for OSPFv2

Vishwas Manral <vishwas.ietf@gmail.com> Tue, 25 August 2009 17:37 UTC

Return-Path: <vishwas.ietf@gmail.com>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057C83A684F for <ospf@core3.amsl.com>; Tue, 25 Aug 2009 10:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 mvWWkVhUk5eg for <ospf@core3.amsl.com>; Tue, 25 Aug 2009 10:37:17 -0700 (PDT)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id EB3FA3A6F56 for <ospf@ietf.org>; Tue, 25 Aug 2009 10:37:16 -0700 (PDT)
Received: by gxk17 with SMTP id 17so4626587gxk.19 for <ospf@ietf.org>; Tue, 25 Aug 2009 10:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IaIzFrRavBDJd+rz/AH4MaHf245VTy5qE9pWJ4L5Heo=; b=Zgye1Ych6Aazf6yWsGGKVm1Tel8hhnr/eToCnLnsgYNBZPOWeb6Luwp8u36QiEJf3H 6eP07m4SertB8no6SrI7vvVreNAzoC8c77VZKOeR2oIkPufsktaESEAPzvWoN4LsIOPl 0l0sRUorJWRCt0yTZeWH0zYIGqZyn7fkz1Ze8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T+3Xae7+kMKU5Dk4INF5qgePE+QW+aKH5tb6UeiceXjuopMjdtrKBDzsiBo14LCXZ5 vc+m36CTEGpvrbM5pG2Nj1wostxEi33j6zEfEYLTN5qRwRiams3H80hYDe3Uba2fADVP TWMVEg/GmJLWm8ivL9l44g6ZqF1LVwAsDLfNQ=
MIME-Version: 1.0
Received: by 10.150.7.5 with SMTP id 5mr11089103ybg.156.1251221835779; Tue, 25 Aug 2009 10:37:15 -0700 (PDT)
In-Reply-To: <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com>
References: <25C684A4-6D5E-4924-892E-758F0AB1A36B@redback.com> <4A8C2F43.6010509@cisco.com> <19964D61-784B-4A71-BD68-9E6A1DAB3DAB@redback.com>
Date: Tue, 25 Aug 2009 10:37:15 -0700
Message-ID: <77ead0ec0908251037y77ca5247h900ef584e7768d28@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Acee Lindem <acee@redback.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: OSPF List <ospf@ietf.org>, Suresh Melam <nmelam@juniper.net>
Subject: Re: [OSPF] Authentication/Confidentiality for OSPFv2
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2009 17:37:18 -0000

Hi Acee,

Though I mostly agree with Paul. The advantage of having something at
the IPsec level is that we do not require protocol specific extensions
as long as IPsec meets the needs as we move forward. an example of
this could be automatic Keying mechanism rather than manual keying.

Thanks,
Vishwas

On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem<acee@redback.com> wrote:
> Hi Paul,
>
> On Aug 19, 2009, at 12:58 PM, Paul Wells wrote:
>
>> Hi Acee,
>>
>> Before we make this a working group document I'd like to hear what real
>> problem in OSPFv2 this proposal is addressing.
>>
>> With draft-ietf-ospf-hmac-sha we are upgrading the authentication
>> algorithms used by OSPFv2 to the same ones commonly used with IPSec. While
>> the optional use of AH does authenticate additional bits of the IP header,
>> I'm not sure I see a significant benefit in that. On the other hand, we lose
>> the replay protection we currently have in OSPFv2.
>
> This would not replace the existing OSPFv2 authentication. Rather, it would
> augment it.
>
>
>>
>> The only new capability I see is the option of encrypting the protocol
>> traffic while, presumably, leaving everything else in the clear. In my
>> opinion if you really care about confidentiality you'll run everything,
>> including OSPF, through an IPSec tunnel.
>
> That's a valid question? What is the group feeling on this?
>
>
>>
>> I'd rather see the WG spend it's time improving RFC 4552 by allowing for
>> automated rekeying (at least on P2P links) rather than simply copying the
>> existing OSPFv3 spec to OSPFv2.
>
> Much of what is going on in this space is not within the charter of the OSPF
> WG. With respect to P2P links, I've thought about defining a mode of
> operation that would relegate OSPF(v3) topologies to P2P and P2MP allowing
> the use of IKEv2 for automated rekeying. In fact, it was one of those ideas
> I meant to propose at an OSPF WG meeting but never got around to it.
>
> Thanks,
> Acee
>
>
>>
>> Regards,
>> Paul
>>
>> Acee Lindem wrote:
>>>
>>> For some time we've discussed adding IPsec support for OSPFv2 analogous
>>> to what we have for OSPFv3. The draft subject draft describes how we'd build
>>> on the OSPFv3 support to support OSPFv2:
>>>   http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt
>>> What are the current thoughts as far as adding this as a WG document?
>>> Thanks,
>>> Acee
>>> P.S. The formatting issues will be fixed in the next
>>> revision._______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>