Re: [Hipsec] Minor correction to rfc7401 4.4.4 state machine

Tom Henderson <tomhend@u.washington.edu> Fri, 03 July 2015 15:08 UTC

Return-Path: <tomhend@u.washington.edu>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201511A88FA for <hipsec@ietfa.amsl.com>; Fri, 3 Jul 2015 08:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0jiymXlOLDV for <hipsec@ietfa.amsl.com>; Fri, 3 Jul 2015 08:08:17 -0700 (PDT)
Received: from mxout25.s.uw.edu (mxout25.s.uw.edu [140.142.234.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780721A8831 for <hipsec@ietf.org>; Fri, 3 Jul 2015 08:08:17 -0700 (PDT)
Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout25.s.uw.edu (8.14.4+UW14.03/8.14.4+UW15.02) with ESMTP id t63F4QUA014839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 08:04:26 -0700
Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW14.04) with ESMTP id t63F4PU5026678; Fri, 3 Jul 2015 08:04:25 -0700
Received: from localhost (Unknown UID 20280@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id t63F4PVU026675; Fri, 3 Jul 2015 08:04:25 -0700
X-Auth-Received: from [73.181.150.17] by hymn02.u.washington.edu via HTTP; Fri, 03 Jul 2015 08:04:25 PDT
Date: Fri, 3 Jul 2015 08:04:25 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <alpine.LRH.2.01.1507030804250.21265@hymn02.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409400-1521102189-1435935865=:21265"
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.3.145716
X-PMX-Server: mxout25.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1800_1899 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS , __USER_AGENT 0'
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/OdmDFC9-5E_OQcwlEtuO3W_2cu4>
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] Minor correction to rfc7401 4.4.4 state machine
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2015 15:08:22 -0000

Gonzalo,
I had a look at the criteria here:

https://www.ietf.org/iesg/statement/errata-processing.html

and it states that this condition should be satisfied to log an erratum:

 Only errors that could cause implementation or deployment problems or significant confusion should be Verified. 

I'm wondering about whether this meets the criteria.  On the one hand, this is a mainstream state transition (I1-SENT gets to I2-SENT upon receiving an R1, not an R2).  On the other hand, this section is clearly informational (section 4.4) and the transition is correctly noted in the Table 3 in this section (also informative) and in the normative Section 6.8.

So, I wonder whether this is in the category of "could cause significant confusion" or rather whether an implementer would just recognize this as an obvious typo in conflict with other parts of the specification.

Any opinions about this?

- Tom

On 06/29/2015 01:36 PM, Gonzalo Camarillo wrote:> Yes, please log an erratum.
> 
> Thanks,
> 
> Gonzalo
> 
> On 29/06/2015 11:20 PM, Tom Henderson wrote:
>>
>>
>> On 06/28/2015 09:51 AM, Darren Lissimore wrote:> Hey all;
>>>
>>> Read through 7401, got to section 4.4.4
>>> ​page 36.
>>> There's an error in the transition from I1-SENT to I2-SENT
>>> ​.​
>>> The draft has it as  recv R2, send I2 and
>>> ​it ​
>>> should be
>>> ​probably be ​
>>> recv R1, send I2
>>> ​as per Table 3 page 29   "recevie r1, process" trigger.
>>>
>>> ​Darren Lissimore