Re: [Hipsec] draft-keranen-hip-over-hip-00

Ari Keranen <ari.keranen@nomadiclab.com> Fri, 12 February 2010 12:27 UTC

Return-Path: <ari.keranen@nomadiclab.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 31A003A78B4 for <hipsec@core3.amsl.com>; Fri, 12 Feb 2010 04:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zRIeSB-hgE-r for <hipsec@core3.amsl.com>; Fri, 12 Feb 2010 04:27:42 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2A77A3A78B3 for <hipsec@ietf.org>; Fri, 12 Feb 2010 04:27:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0F52C4E6C8; Fri, 12 Feb 2010 14:28:58 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtlv9W+bdQtB; Fri, 12 Feb 2010 14:28:57 +0200 (EET)
Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9BE1F4E6C4; Fri, 12 Feb 2010 14:28:57 +0200 (EET)
Message-ID: <4B754989.5090209@nomadiclab.com>
Date: Fri, 12 Feb 2010 14:28:57 +0200
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <4B72A248.9090901@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A762@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A762@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00
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: Fri, 12 Feb 2010 12:27:43 -0000

Henderson, Thomas R wrote:
>>> 2) previously in RFC5201, we adopted the convention that
>> the roles of
>>> Initiator and Responder are abandoned once the base exchange 
>>> completes, so this would require implementations to keep that
>>> state around (might require some comment here or in 5201bis).
>> With the ESP mode you don't need this information, so I assume you
>> are referring to the ESP-TCP mode where the Initiator initiates 
>> also the TCP connection, right? Although even in this case the
>> information is needed only right after the BEX.
>> 
>> If you think it would be beneficial to not require keeping this 
>> information (even for such a short period of time), we could define
>> that the host with lower HIT value starts the TCP connection. 
>> Actually, if we want to support negotiation of the transport mode
>> after the BEX using UPDATEs, this would be a good idea.
> 
> Yes, I was referring to ESP-TCP mode.  Your suggestion about the
> lower HIT value seems fine to me.

OK, great. This will be included in the next revision.

>>> 4) Have you thought about SCTP instead of TCP for this use case?
>> Not really, but I don't see much benefit of using SCTP instead of
>> TCP in this scenario (e.g., we have already framing thanks to HIP 
>> header, HOL blocking doesn't sound like a probable scenario, DoS
>> protection is provided by HIP). And since TCP is still much more
>> widely supported, using that for fragmentation handling seems like
>> a good idea. Or am I missing something?
>> 
>> That said, having SCTP as one extra mode would fit well into the 
>> specification.
>> 
> 
> I was thinking initially that SEQPACKET might offer slightly better
> semantics than STREAM to this application, but having read the sctp
> API draft just now, I'm not sure that the work to deconflict the SCTP
> multihoming from HIP multihoming is worth it (i.e. you would have to
> provide some explicit guidelines on how to use the SCTP API, where
> TCP is pretty clear cut to developers).

OK. Then I think it makes sense to leave SCTP out of the draft, at least 
for the time being. Thanks for the analysis!


Cheers,
Ari