Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai

Acee Lindem <acee.lindem@ericsson.com> Wed, 13 April 2011 15:01 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 144B1E078F for <ospf@ietfc.amsl.com>; Wed, 13 Apr 2011 08:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iT6IU-tIywH for <ospf@ietfc.amsl.com>; Wed, 13 Apr 2011 08:01:57 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 2270FE0778 for <ospf@ietf.org>; Wed, 13 Apr 2011 08:01:57 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DF1oB1012812; Wed, 13 Apr 2011 10:01:53 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([147.117.20.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 13 Apr 2011 11:01:49 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Date: Wed, 13 Apr 2011 11:01:47 -0400
Thread-Topic: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
Thread-Index: Acv567cx8/QTKvS6Q06GP3nYLT1BOw==
Message-ID: <47E0DC9D-E5B3-40CB-94E1-8A915D7DAE62@ericsson.com>
References: <566PDLFAb2496S04.1302586047@web04.cms.usa.net> <BANLkTimM8QO9p1pRNkFTougUgbKH0b=V3Q@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037D65@INBANSXCHMBSA1.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 13 Apr 2011 15:01:58 -0000

Hi Manav,

OTOH, we could add the strictly increasing 64 bit sequence number to OSPFv3 Auth Trailer draft without too much trouble. Even though it might not end up to be exactly what is used for the OSPFv2 draft, it seems there is a requirement to do something better than is done today. Right now, the OSPFv2 IP layer security draft still has all the nounce stuff in it. The 64 sequence was primarily a product of the E-mail thread between you, Sam, and myself.

Thanks,
Acee

On Apr 12, 2011, at 4:41 PM, Bhatia, Manav (Manav) wrote:

Hi Vishwas,

As i have explained earlier, AT is a complete solution and none of the current proposals in KARP (nonce ID, boot count, etc) will be invalidating it. AT provides the basic infrastructure over which other these will get built. The two are thus not comparable.

Cheers, Manav

________________________________
From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, April 12, 2011 10.32 PM
To: Michael Barnes
Cc: Bhatia, Manav (Manav); curtis@occnc.com<mailto:curtis@occnc.com>; Abhay Roy; ospf@ietf.org<mailto:ospf@ietf.org>
Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai

Hi Manav/ Mike,

Though it is ok to have another draft invalidate this one after some time. It would be a challenge to get implementations to change as fast (if at all).

In my view if the current solution is deemed incomplete, we can correct the current solution.

Thanks,
Vishwas
On Mon, Apr 11, 2011 at 10:27 PM, Michael Barnes <michael_barnes@usa.net<mailto:michael_barnes@usa.net>> wrote:
Hello Manav,

------ Original Message ------
Received: Mon, 11 Apr 2011 10:05:36 PM PDT
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com<mailto:manav.bhatia@alcatel-lucent.com>>
To: Michael Barnes <michael_barnes@usa.net<mailto:michael_barnes@usa.net>>,        "curtis@occnc.com<mailto:curtis@occnc.com>"
<curtis@occnc.com<mailto:curtis@occnc.com>>, Abhay Roy <akr@cisco.com<mailto:akr@cisco.com>>Cc: "ospf@ietf.org<mailto:ospf@ietf.org>"
<ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: [OSPF] WG Last Call for Supporting Authentication Trailer for
OSPFv3 - draft-ietf-ospf-auth-trai

> Hi Michael,
>
> > > right direction and would not have to be revisited quite as soon if
> > > something more robust were proposed.
> > >
> > > Bottom line.  Falls short of what I'd like to see but no objection.
> > >
> > > Curtis
> >
> > I agree with Curis. I'd really like to see the first version
> > of this spec at
> > least have the extended sequence number as is being discussed for v2.
>
> I disagree that AT should have a 64 bit sequence space in the base
specification primarily because we are not yet sure if the KARP boot count
approach is what the WG will finally converge on (in which case we would need
an extended sequence space). Also note that the AT provides an "Auth Type"
field which can be assigned a new value (similar to how it will be done for
OSPFv2) once we decide to move to a different scheme. The same standard that
extends the OSPFv2 sequence space can also do it for OSPFv3 AT block - really
hardly an overhead.
>
> Also note that you could consider this proposal as just bringing OSPFv3 at
par with OSPFv2. Once this is done, any proposal that extends OSPFv2 will
natively work for OSPFv3 as well.

So you are saying that this flaw is okay with you? I'd rather hold off on
pushing this forward until this flaw is fixed. And I think waiting to see what
happens in KARP might be a good idea.

Regards,
Michael

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf