IETF Logo Mail Archive

Re: [CGA-EXT] SEND checksum issue in current RFC 3791 - update needed

arno@natisbad.org (Arnaud Ebalard) Thu, 17 September 2009 08:21 UTC

Return-Path: <arno@natisbad.org>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3DB3A6A78 for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 01:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.577
X-Spam-Level:
X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 K1TP-jjZA+52 for <cga-ext@core3.amsl.com>; Thu, 17 Sep 2009 01:21:26 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 393813A676A for <cga-ext@ietf.org>; Thu, 17 Sep 2009 01:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=hqyo0oXrzN2 z+ofPgz6tLab6PVe9DCKrGhUtBKGfCFE=; b=m+xWpGi583UCWT0rmqvYeylbkzh tnx7qxhTY5HeOmNfTp4hjNrmyX7XW3+0SPAkPDasS9f+RfticTdZSxu9wfE689vG EVMaB7alxsDGZ8CvW+mQcQMsIZK8oaajBrsa9C2s/f3xnsjdRTIFtANHFSj6O0Ut SbsVM/xkICiUilhA=
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1MoCFq-0003nV-So; Thu, 17 Sep 2009 10:22:15 +0200
From: arno@natisbad.org
To: Eric Levy-Abegnoli <elevyabe@cisco.com>
References: <002501ca376a$5eb39950$3a0c6f0a@china.huawei.com> <4AB1EB54.4000903@cisco.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:090917:shengjiang@huawei.com::0WGi9ubdkyjhZk7K:000000000000000000000000000000000000000036Dr
X-Hashcash: 1:20:090917:cga-ext@ietf.org::HysuEh1+kWBU8DFz:02FSX
X-Hashcash: 1:20:090917:elevyabe@cisco.com::N70Rdgs9/vzjZ7Pb:00000000000000000000000000000000000000000003luv
X-Hashcash: 1:20:090917:wdwang@bupt.edu.cn::7smF7SMOLvghTsJN:00000000000000000000000000000000000000000005LAB
Date: Thu, 17 Sep 2009 10:22:55 +0200
In-Reply-To: <4AB1EB54.4000903@cisco.com> (Eric Levy-Abegnoli's message of "Thu, 17 Sep 2009 09:55:00 +0200")
Message-ID: <871vm6q8tc.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: 'wdwang' <wdwang@bupt.edu.cn>, cga-ext@ietf.org
Subject: Re: [CGA-EXT] SEND checksum issue in current RFC 3791 - update needed
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 08:21:27 -0000

Hi,

Eric Levy-Abegnoli <elevyabe@cisco.com> writes:

> Sheng,
> Currently, I see onle one possibility, which is A. It is
> un-ambiguously specified in rfc3971.

I respectfully disagree (not on the definitive solution). My previous
post in March 2008 and the one from Sheng just prove this is not
"un-ambiguously" specified. 

> And it has been implemented by multiple vendors.

I checked the code and NTT Docomo SEND daemon does 'A' (i should have
checked before my first reply to Sheng):

It computes the checksum on current ICMPv6 message before the Signature
computation, uses that during the signature step and then recomputes the
checksum after the signature option has been added to the message.

> Moving to B would not be backward compatible and would create
> inter-operability issues.

Clarifying the spec would help in all cases.

Cheers,

a+

v2.23.0 | Report a Bug | By Email