[IPsec] note on ike fragmentation and ike over tcp

Paul Wouters <pwouters@redhat.com> Tue, 12 March 2013 14:41 UTC

Return-Path: <pwouters@redhat.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F13AD21F8C08 for <ipsec@ietfa.amsl.com>; Tue, 12 Mar 2013 07:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wipNaslwBx-p for <ipsec@ietfa.amsl.com>; Tue, 12 Mar 2013 07:41:24 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca []) by ietfa.amsl.com (Postfix) with ESMTP id B7A1B21F8C04 for <ipsec@ietf.org>; Tue, 12 Mar 2013 07:41:24 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZQJlZ40Jjz5LC for <ipsec@ietf.org>; Tue, 12 Mar 2013 10:41:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dclTktUvCh-E for <ipsec@ietf.org>; Tue, 12 Mar 2013 10:41:09 -0400 (EDT)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com []) by mx.nohats.ca (Postfix) with ESMTP for <ipsec@ietf.org>; Tue, 12 Mar 2013 10:41:09 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 1570A80860; Tue, 12 Mar 2013 10:41:08 -0400 (EDT)
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id 092FA8043D for <ipsec@ietf.org>; Tue, 12 Mar 2013 10:41:08 -0400 (EDT)
Date: Tue, 12 Mar 2013 10:41:08 -0400
From: Paul Wouters <pwouters@redhat.com>
X-X-Sender: paul@bofh.nohats.ca
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
Message-ID: <alpine.LFD.2.03.1303121024300.21629@nohats.ca>
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [IPsec] note on ike fragmentation and ike over tcp
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 14:41:27 -0000

(missed from the jabber room)

The bug mentioned that there was a lot of IKE fragments for IKEv1 without
seeing the FRAGMENTATION vendorid was solved. It was iOS 6.0 and they
fixed it since. (either in 6.01 or 6.1)

It did cause people to be forced to implement fragmentation for IKEv1.

The best "specification" I found was at Microsoft:


However note that it seems most (every?) implementation only uses fragment
ID = 1. Probably because that field is useless and an IETF review would
have found that and kicked it out :)

There seem to be different tresholds for when to do fragmentation. Stock
racoon uses 552, while racoon on iOS uses 1280. We (libreswan) ran into
strange Linux kernel issues for IPv6 when using 552 (might be our own
fault). Neither upstream racoon or iOS racoon treats IPv4 different from
IPv6. Libreswan uses 552 for IPv4 and 1240 for IPv6 but that might change,
as our exposure and interop experience is rather new (and mostly with
racoon or racoon-derivatives code such as strongswan)

Note also that it is likely there could be interoperability issues
because the racoon code (and the strongswan port of that) are directly
using sizeof(struct) for wire format, so we might see strange issues on
certain CPUs now or in the future due to alignments.

The fragmentation seems pretty straightforward. I personally like
not needing to rely on TCP (which can be trivially DOS'ed using
an unauthenticated TCP RST packet). So I'm with Tero that if IKE
fragmentation works, and it seems that it does, the incentive for
implementing IKE over TCP is low, while the changes are pretty invasive.

So I am okay with abandoning it for now.