IETF Logo Mail Archive

[IPsec] TSVDIR-ish review of draft-ietf-ipsecme-ikev2-fragmentation-04

Joe Touch <touch@isi.edu> Tue, 22 October 2013 00:06 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FD411E87A7; Mon, 21 Oct 2013 17:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mns1sNJGay2c; Mon, 21 Oct 2013 17:06:47 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1BB11E8771; Mon, 21 Oct 2013 17:06:46 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9M06DeV005272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 17:06:17 -0700 (PDT)
Message-ID: <5265C19B.30108@isi.edu>
Date: Mon, 21 Oct 2013 17:06:51 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Stiemerling <martin.stiemerling@neclab.eu>, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, tsvwg <tsvwg@ietf.org>
References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu>
In-Reply-To: <523CB9CB.7060507@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tsv-dir@ietf.org" <tsv-dir@ietf.org>
Subject: [IPsec] TSVDIR-ish review of draft-ietf-ipsecme-ikev2-fragmentation-04
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, 22 Oct 2013 00:06:53 -0000

Hi, all,

I've reviewed the following doc for TSVDIR:
	draft-ietf-ipsecme-ikev2-fragmentation-04

Although this is not intended as a complete TSVDIR review, I have 
checked for the typical issues.

Joe

-------------------------------------------------------------------

draft-ietf-ipsecme-ikev2-fragmentation-04
	
This doc makes the case that IKEv2 should implement its own 
frag/reassembly mechanism, because some NATs don't pass IP fragments.

First, the issue with NATs and fragments should be made more clear, 
especially citing existing descriptions of this issue, e.g., RFC4787. 
Note that NATs which do not pass fragments violate RFQ-14 of that BCP 
RFC, and it might be useful to report this issue to the vendor.

Second, it is not clear why this issue is being handled inside IKE. 
Appendix A provides a design rationale, but it clearly trades 
computation and space overhead for local storage, and still permits DOS 
attacks (e.g., overloading the receiver with false fragments).

An equally viable solution (see ** below) would involve placing a single 
signed IKE message into a single IP packet, fragmenting that packet, and 
transmitting those fragments inside UDP datagrams. This approach could 
use the innermost IP encapsulation as the reassembly layer.

**: Although this approach is susceptible to fragmentation overload, so 
too is transmitting the original message over IP that is naturally 
fragmented at the network layer anyway - this introducing no new 
vulnerability.

This IP-encapsulated IKE message would need the same negotiation 
described in section 2.3, but would avoid the complexity of most of the 
rest of the document, relying instead on existing IP reassembly.

In conclusion, I don't see the need for the level of detail and 
mechanism proscribed, basically because it reinvents the wheel, but see 
no other substantial issues with it.

Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 
4821), and should be described as such.

---

v2.23.0 | Report a Bug | By Email