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
- [Hipsec] [Fwd: New Version Notification for draft… Ari Keranen
- [Hipsec] draft-keranen-hip-over-hip-00 Henderson, Thomas R
- Re: [Hipsec] draft-keranen-hip-over-hip-00 Ari Keranen
- Re: [Hipsec] ??: draft-keranen-hip-over-hip-00 Ari Keranen
- Re: [Hipsec] draft-keranen-hip-over-hip-00 Miika Komu
- Re: [Hipsec] draft-keranen-hip-over-hip-00 Ari Keranen
- Re: [Hipsec] draft-keranen-hip-over-hip-00 Henderson, Thomas R
- Re: [Hipsec] draft-keranen-hip-over-hip-00 Ari Keranen