Re: [OSPF] [Technical Errata Reported] RFC6506 (3567)
"Michael Barnes" <michael_barnes@usa.net> Sun, 31 March 2013 18:48 UTC
Return-Path: <michael_barnes@usa.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22621F862B for <ospf@ietfa.amsl.com>; Sun, 31 Mar 2013 11:48:56 -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=[RCVD_NUMERIC_HELO=2.599]
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 C2yz+nQN5faS for <ospf@ietfa.amsl.com>; Sun, 31 Mar 2013 11:48:48 -0700 (PDT)
Received: from co03.mbox.net (co03.mbox.net [165.212.64.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F221F8518 for <ospf@ietf.org>; Sun, 31 Mar 2013 11:48:45 -0700 (PDT)
Received: from co03.mbox.net (localhost [127.0.0.1]) by co03.mbox.net (Postfix) with ESMTP id 3Zf5LN2lhKzvWs4; Sun, 31 Mar 2013 18:48:44 +0000 (UTC)
X-USANET-Received: from co03.mbox.net [127.0.0.1] by co03.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 472RcEsWO4528M03; Sun, 31 Mar 2013 18:48:40 -0000
X-USANET-Routed: 3 gwsout-vs Q:bmvirus
X-USANET-GWS2-Tagid: UNKN
Received: from ca33.cms.usa.net [165.212.11.133] by co03.mbox.net via smtad (C8.MAIN.3.89G) with ESMTP id XID476RcEsWO0128X03; Sun, 31 Mar 2013 18:48:40 -0000
X-USANET-Source: 165.212.11.133 OUT michael_barnes@usa.net ca33.cms.usa.net
X-USANET-MsgId: XID476RcEsWO0128X03
Received: from web08.cms.usa.net [165.212.8.208] by ca33.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 096RcEsWO9008M33; Sun, 31 Mar 2013 18:48:40 -0000
X-USANET-Auth: 165.212.8.208 AUTO michael_barnes@usa.net web08.cms.usa.net
Received: from 173.22.132.108 [173.22.132.108] by web08.cms.usa.net (USANET web-mailer C8.MAIN.3.88W); Sun, 31 Mar 2013 18:48:39 -0000
Date: Sun, 31 Mar 2013 11:48:39 -0700
From: Michael Barnes <michael_barnes@usa.net>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, "vishwas.manral@hp.com" <vishwas.manral@hp.com>, "acee.lindem@ericsson.com" <acee.lindem@ericsson.com>, "stbryant@cisco.com" <stbryant@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "akr@cisco.com" <akr@cisco.com>, "acee.lindem@ericsson.com" <acee.lindem@ericsson.com>
X-Mailer: USANET web-mailer (C8.MAIN.3.88W)
Mime-Version: 1.0
Message-ID: <573RcEsvn3424S08.1364755719@web08.cms.usa.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Z-USANET-MsgId: XID096RcEsWO9008X33
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567)
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: Sun, 31 Mar 2013 18:48:56 -0000
Hi Manav, For OSPFv2, when cryptographic authentication is being used the LLS checksum is not calculated (RFC5613 section 2.2). I've never heard of anyone having a problem knowing that CA was being used on the interface before the LLS checksum was calculated. I think that OSPFv3 should be equivalent to OSPFv2 in this regard. In any case, I think that RFC6506 should have specified how the LLS checksum would be handled. Obviously there are differing opinions and when you leave something like this undefined it can lead to interoperability issues. Regards, Michael ------ Original Message ------ Received: Sat, 30 Mar 2013 10:25:59 PM PDT From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> To: "vishwas.manral@hp.com" <vishwas.manral@hp.com>, "acee.lindem@ericsson.com" <acee.lindem@ericsson.com>, "stbryant@cisco.com" <stbryant@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "akr@cisco.com" <akr@cisco.com>, "acee.lindem@ericsson.com" <acee.lindem@ericsson.com>Cc: "ospf@ietf.org" <ospf@ietf.org> Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) > Hi Marek, > > When constructing the LLS data block it may not always be possible for an implementation to know whether there is authentication being used on a link or not. Sure there are ways for us to figure this out but it may not be a very modular approach (really an implementation specific issue). > > If you follow rfc 6506 and do as it says then you can always choose NOT to verify the LLS checksum upon reciept and still be compliant to 6506. > > This way nothing changes - Your original code for LLS still computes the checksum regardless of whether OSPFv3 AT is configured or not. The AT code computes the digest of the packet including the LLS data block. > > The reciever verifies the AT data block and accepts the packet if it matches with whats carried in the packet. Its now an implementation specific issue whether it wants to verify the LLS checksum or not. > > Given this I don't think the errata raised is correct - more so, because this isnt really an error in the RFC. > > Even if we'd discussed this issue when we were writing this RFC we would have left it as an implementation specific behavior at the RX side based on the modularity argument. > > Based on this argument I would also reject the errata 3568 that has been raised. > > Cheers, Manav > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Wednesday, March 27, 2013 6:08 PM > > To: Bhatia, Manav (Manav); vishwas.manral@hp.com; > > acee.lindem@ericsson.com; stbryant@cisco.com; > > adrian@olddog.co.uk; akr@cisco.com; acee.lindem@ericsson.com > > Cc: mkarasek@cisco.com; ospf@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC6506 (3567) > > > > The following errata report has been submitted for RFC6506, > > "Supporting Authentication Trailer for OSPFv3". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6506&eid=3567 > > > > -------------------------------------- > > Type: Technical > > Reported by: Marek Karasek <mkarasek@cisco.com> > > > > Section: 2.2 > > > > Original Text > > ------------- > > Consistent with OSPFv2 Cryptographic Authentication > > [RFC2328], both OSPFv3 header checksum calculation and > > verification are omitted when the OSPFv3 authentication > > mechanism described in this specification is used. > > > > Corrected Text > > -------------- > > OSPFv3 authentication mechanism provides capability to detect > > corruption of OSPFv3 packet, which is under non authenticated > > operation achieved using OSPFv3 header checksum [RFC 5340] > > and LLS data block checksum [RFC 5613]. In spirit of OSPFv2 > > Cryptographic Authentication [RFC2328], OSPFv3 header > > checksum and LLS Data Block Checksum calculation and > > verification are omitted when the OSPFv3 authentication > > mechanism described in this specification is used. > > > > Notes > > ----- > > RFC does not specify how to work with LLS Data Block > > Checksum. Errata suggests omit checksum > > calculation/verification in the same way like for OSPFv3 > > header checksum. > > > > 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. > > > > -------------------------------------- > > RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11) > > -------------------------------------- > > Title : Supporting Authentication Trailer for OSPFv3 > > Publication Date : February 2012 > > Author(s) : M. Bhatia, V. Manral, A. Lindem > > 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] [Technical Errata Reported] RFC6506 (3567) RFC Errata System
- Re: [OSPF] [Technical Errata Reported] RFC6506 (3… t.petch
- Re: [OSPF] [Technical Errata Reported] RFC6506 (3… Marek Karasek (mkarasek)
- Re: [OSPF] [Technical Errata Reported] RFC6506 (3… Bhatia, Manav (Manav)
- Re: [OSPF] [Technical Errata Reported] RFC6506 (3… Michael Barnes
- Re: [OSPF] [Technical Errata Reported] RFC6506 (3… Marek Karasek (mkarasek)