Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 03 November 2010 16:47 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 942E33A69D7 for <ospf@core3.amsl.com>; Wed, 3 Nov 2010 09:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 hVu1EiCoa3Wx for <ospf@core3.amsl.com>; Wed, 3 Nov 2010 09:47:05 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 620023A68D7 for <ospf@ietf.org>; Wed, 3 Nov 2010 09:47:05 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id oA3Gl9bQ012746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Nov 2010 11:47:11 -0500 (CDT)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oA3Gl7Xf030252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Nov 2010 22:17:08 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 3 Nov 2010 22:17:07 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "Obrien, John W" <john.w.obrien@lmco.com>, "ospf@ietf.org" <ospf@ietf.org>
Date: Wed, 03 Nov 2010 22:17:14 +0530
Thread-Topic: [OSPF] [Technical Errata Reported] RFC4552 (2599)
Thread-Index: Act66ts2ngSySVX+T9GNd9wfBP4QTQAiTH7gAAA0mWA=
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF4B13B31@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <20101102155316.C350CE06B7@rfc-editor.org> <AANLkTi=2S_sngGZK3sQzdhCD9hOPnD5xkd989QkaAP6w@mail.gmail.com> <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.com>
In-Reply-To: <7AA4282413159948AD514B064BE1478D1840AE6F81@HVXMSP5.us.lmco.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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31
Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)
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: Wed, 03 Nov 2010 16:47:06 -0000

John,

There are several 4301 compliant implementations that may NOT support AH. If 4552 mandates AH, then many implementations that are Ipsec compliant today will not be able to provide security for OSPF as they may not be supporting AH (and may also not have in their roadmap to support it in the future).

BTW, RFC 5796, which explains how PIM-SM can use Ipsec to secure its packets also has ESP as a MUST and AH as a MAY.

Cheers, Manav

> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On 
> Behalf Of Obrien, John W
> Sent: Wednesday, November 03, 2010 10.00 PM
> To: ospf@ietf.org
> Subject: Re: [OSPF] [Technical Errata Reported] RFC4552 (2599)
> 
> [My original reply was rejected by the list. Resent for 
> posterity now that I've subscribed.]
> 
> Vishwas,
> 
> Thanks for your prompt response.
> 
> I do not dispute that ESP provides authentication as well, 
> but I don't believe that fact invalidates this errata. My 
> stated rationale still holds, does it not? If an 
> implementation desires to provide authentication without also 
> providing confidentiality (as is permitted by 4552), AH alone 
> can perform that function. Furthermore, AH authenticates more 
> of the packet than does ESP. What is the rationale, 
> therefore, for attaching the stronger "MUST" to ESP and the 
> weaker "MAY" to AH in Section 3, Authentication?
> 
> The errata may be invalid because the authors' intention is 
> to mandate ESP support in all cases, regardless of the line 
> of thought above, which I accept. That would mean that my 
> comment against the specification should be submitted and 
> discussed in a different forum.
> 
> Regards,
> John
> 
> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
> Sent: Tuesday, November 02, 2010 8:05 PM
> To: RFC Errata System
> Cc: mukesh.gupta@tropos.com; nmelam@juniper.net; 
> stbryant@cisco.com; adrian.farrel@huawei.com; 
> acee@redback.com; akr@cisco.com; ospf@ietf.org; Obrien, John W
> Subject: EXTERNAL: Re: [OSPF] [Technical Errata Reported] 
> RFC4552 (2599)
> 
> Hi,
> 
> This errata is wrong. ESP provides authentication as well as
> confidentiality, have a look at RFC 4301.
> 
> Thanks,
> Vishwas
> 
> On Tue, Nov 2, 2010 at 8:53 AM, RFC Errata System
> <rfc-editor@rfc-editor.org> wrote:
> >
> > The following errata report has been submitted for RFC4552,
> > "Authentication/Confidentiality for OSPFv3".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=4552&eid=2599
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: John W. O'Brien <john.w.obrien@lmco.com>
> >
> > Section: 3
> >
> > Original Text
> > -------------
> > In order to provide authentication to OSPFv3, 
> implementations MUST support ESP and MAY support AH.
> >
> >
> > Corrected Text
> > --------------
> > In order to provide authentication to OSPFv3, 
> implementations MUST support AH and MAY support ESP.
> >
> > Notes
> > -----
> > Authentication can be provided by an implementation that 
> supports AH only.
> >
> > Instructions:
> > -------------
> > This errata is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC4552 (draft-ietf-ospf-ospfv3-auth-08)
> > --------------------------------------
> > Title               : Authentication/Confidentiality for OSPFv3
> > Publication Date    : June 2006
> > Author(s)           : M. Gupta, N. Melam
> > Category            : PROPOSED STANDARD
> > Source              : Open Shortest Path First IGP
> > Area                : Routing
> > Stream              : IETF
> > Verifying Party     : IESG
> > _______________________________________________
> > 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
>