Re: [OSPF] [Technical Errata Reported] RFC6506 (3567)
"Marek Karasek (mkarasek)" <mkarasek@cisco.com> Fri, 29 March 2013 22:10 UTC
Return-Path: <mkarasek@cisco.com>
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 3FC0821F9015 for <ospf@ietfa.amsl.com>; Fri, 29 Mar 2013 15:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
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 aMWBcnA+ZkXo for <ospf@ietfa.amsl.com>; Fri, 29 Mar 2013 15:10:26 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3721F900F for <ospf@ietf.org>; Fri, 29 Mar 2013 15:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3637; q=dns/txt; s=iport; t=1364595026; x=1365804626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=unJE8euaLjSSxur2ipFgVQlrwanu3l6DHRcpuACzTCY=; b=lFzwnfYUZ7tXydMypAEFQ71Qj9s4vXIB01fbZFP+LTqEg1Q6vM2a+1UW ObEvDMR9Mx0jNy1t410k2PO7H4VfOSLwAnY5zEO+dC0SHkx3j3O2+4Nvg Xx3vAMQqfBpQrm2hkw3g030em+nI+WMlf+yH8LmGy+tlgUZPQkDKWCvwX 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFANIPVlGtJXG+/2dsb2JhbAApGoM6vz6BChZ0gh8BAQEDAQEBATc0CwUHBAIBCBEEAQELFAkHJwsUCQgCBAENBQiIBgYMLr9ejVqBHCYLBwaCWWEDp3aDC3qBLg
X-IronPort-AV: E=Sophos;i="4.87,375,1363132800"; d="scan'208";a="190051308"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 29 Mar 2013 22:10:21 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2TMALF5002693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Mar 2013 22:10:21 GMT
Received: from xmb-rcd-x11.cisco.com ([169.254.1.206]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 17:10:21 -0500
From: "Marek Karasek (mkarasek)" <mkarasek@cisco.com>
To: "t.petch" <ietfc@btconnect.com>, "manav.bhatia@alcatel-lucent.com" <manav.bhatia@alcatel-lucent.com>, "vishwas.manral@hp.com" <vishwas.manral@hp.com>, "acee.lindem@ericsson.com" <acee.lindem@ericsson.com>
Thread-Topic: [OSPF] [Technical Errata Reported] RFC6506 (3567)
Thread-Index: AQHOKuf5RpxnQnNRs0eE494S+KVBBJi9LzO4gAAFwmA=
Date: Fri, 29 Mar 2013 22:10:21 +0000
Message-ID: <E7523A682FBA7E498E8FAF27332266AA0F5892E8@xmb-rcd-x11.cisco.com>
References: <20130327123752.EFE2DB1E002@rfc-editor.org> <018b01ce2cc1$dd8defa0$4001a8c0@gateway.2wire.net>
In-Reply-To: <018b01ce2cc1$dd8defa0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.25.122]
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] [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: Fri, 29 Mar 2013 22:10:28 -0000
Hi Tom, RFC 6506 specifies how to work with OSPFv3 header checksum, but does not specify how to work with LLS data block checksum. For interoperability reasons it would be very useful if it's documented. There are basically only two options: a) compute LLS checksum as usual b) omit, like for OSPFv3 Header checksum Errata suggests b) because I do not see why to authenticate portion of packet 2x. It may be seen as operational change if there's some implementation doing a). Are you aware of any? Thanks marek -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of t.petch Sent: Friday, March 29, 2013 10:10 PM To: manav.bhatia@alcatel-lucent.com; vishwas.manral@hp.com; acee.lindem@ericsson.com Cc: ospf@ietf.org Subject: Re: [OSPF] [Technical Errata Reported] RFC6506 (3567) Looks like a functional change to me. Tom Petch ----- Original Message ----- From: "RFC Errata System" <rfc-editor@rfc-editor.org> To: <manav.bhatia@alcatel-lucent.com>; <vishwas.manral@hp.com>; <acee.lindem@ericsson.com>; <stbryant@cisco.com>; <adrian@olddog.co.uk>; <akr@cisco.com>; <acee.lindem@ericsson.com> Cc: <ospf@ietf.org>; <rfc-editor@rfc-editor.org> Sent: Wednesday, March 27, 2013 12:37 PM > 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)