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