[Hipsec] (no subject)

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Tue, 19 October 2010 14:54 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1E83A68BE for <hipsec@core3.amsl.com>; Tue, 19 Oct 2010 07:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.356
X-Spam-Level:
X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 88c5TxyYjHPU for <hipsec@core3.amsl.com>; Tue, 19 Oct 2010 07:54:18 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 5C92C3A68B8 for <hipsec@ietf.org>; Tue, 19 Oct 2010 07:54:17 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9JEti5Y010177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Oct 2010 07:55:45 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9JEtiru022237; Tue, 19 Oct 2010 07:55:44 -0700 (PDT)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9JEtipV022231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Oct 2010 07:55:44 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 19 Oct 2010 07:55:44 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Tobias Heer' <heer@cs.rwth-aachen.de>
Date: Tue, 19 Oct 2010 07:55:41 -0700
Thread-Index: ActvnbNJ0h14T+frT/+SXdIUel0uGg==
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEC451A0E@XCH-NW-10V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: HIP WG <hipsec@ietf.org>
Subject: [Hipsec] (no subject)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 19 Oct 2010 14:54:19 -0000

> -----Original Message-----
> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de]
> Sent: Tuesday, October 19, 2010 7:25 AM
> To: Henderson, Thomas R
> Cc: HIP WG
> Subject: Re: [Hipsec] Completing 5201 state machine
>
> Hi Tom,
>
> thanks for the clarification.
>
> Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R:
>
> [...]
> >>>
> >>> OpenHIP allows CLOSE in states ESTABLISHED, CLOSING,
> >> CLOSED, and R2_SENT, but does not process it in this state.
> >>>
> >
> > <snip>
> >
> >>
> >> Above you said that OpenHIP wouldn't process CLOSE messages
> >> in state R2_SENT. What do you mean by that? Isn't sending a
> >> CLOSE_ACK (as you mention for 2.) such processing? Am I
> >> confusing something here?
> >>
> >
> > Sorry for not being clear; the "this state" in the above
> explanation refers to state I2-sent, not R2-sent.
> >
> What is your opinion on processing CLOSE messages in state
> I2-sent? Do you have reasons why you don't process it in that state?
>

I can't recall exactly the reason for this decision, but another possible scenario:

1.) remote host sends CLOSE
2.) local host sends CLOSE_ACK, moves to CLOSED.  CLOSE_ACK lost
3.) local host tries to immediately set up the session again, sends I1, receives (stateless) R1
4.) local host sends I2.  Meanwhile, remote host is still in CLOSING state until it gets I2, which it accepts and moves back to R2-sent.  Here it it more helpful for the local host to just ignore the (stale) CLOSE from the past association

Again, this is somewhat of a contrived scenario.  I am fairly neutral as to how to handle this since these seem to be unlikely scenarios, and would be willing to adopt your suggestion.

- Tom