Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt

"Valery Smyslov" <svanru@gmail.com> Thu, 10 October 2013 06:12 UTC

Return-Path: <svanru@gmail.com>
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 7CD0811E8132 for <ipsec@ietfa.amsl.com>; Wed, 9 Oct 2013 23:12:58 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599]
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 3bp8A4XRa6Hj for <ipsec@ietfa.amsl.com>; Wed, 9 Oct 2013 23:12:58 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C02C511E8135 for <ipsec@ietf.org>; Wed, 9 Oct 2013 23:12:55 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id w6so1676250lbh.33 for <ipsec@ietf.org>; Wed, 09 Oct 2013 23:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=CR5uf9Bn8TXjqfyrz3AHuH297locY1+bBuv73PfPbtI=; b=i/g3mIitRS62mJzX9osnct1pENWtPnegigS2XifO3PpV/8WRt77b/TckBVOLJhwnlM IOaUXWGVfR5/zN/7ElhYHsAn0IswSJS4q2vG6qc3UBRimbjShcJNL3IGjHnoFkcYUyPI xGz1yf/hbgF6RbJFuzMLe5ygTPEQLI7tzL+vidTLXOSvWfwXnwOsMkvaTQXp+ObXw2vX HvfImZ5WFBtQQpRqjnhqfE1SrRVRABJhCNp6QvrjViujb3Fdzk/35Zq0zMZC7QRnp2+s M0lelocwFbVS+PtWPWyR/4skC7NTblOPmXzJAUbGfgsdZTMg8lXNnebUyVotRAE0SjtN E37Q==
X-Received: by 10.152.45.106 with SMTP id l10mr10038272lam.12.1381385574842; Wed, 09 Oct 2013 23:12:54 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k6sm38637021lae.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 23:12:54 -0700 (PDT)
Message-ID: <F7F92C485823496183DF1A5951A80824@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Paul Wouters <paul@cypherpunks.ca>
References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <alpine.LFD.2.10.1310041144500.10965@bofh.nohats.ca> <E46CD124E88F442495758F38BC026897@chichi> <alpine.LFD.2.10.1310081048530.7675@bofh.nohats.ca> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <5256426B.4030707@gmail.com>
Date: Thu, 10 Oct 2013 10:13:01 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
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: Thu, 10 Oct 2013 06:12:58 -0000

>> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is
>> not useful
>> for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram
>> size that is not fragmented by IP level. In IKE its the goal is 
>> different -
>> to find _some_reasonable_ IP datagram size that is not fragmented by IP.
>>
>> If we have the size that is guaranteed to not be fragmented,
>> no PMTU discovery will be needed. As far as I understand, for IPv6
>> it is 1280 bytes. But as far as I know, there's no such value for IPv4.
>> If we mandate (or recommend) using really small value e.g. 128 bytes,
>> than the perfomance will suffer badly, so it it not a good option.
>> I'm especially worring about network I'm not familiar with -
>> mobile networks or other constrained environments.
>> It would be great if some experts in such networks could clarify this.
>>
> I'm even more worried that if we use small fragments, reliability will 
> deteriorate. Because we do not have per-packet acknowledgement, and so if 
> any fragment is dropped, the whole message must be resent. This is 
> probably a greater risk in mobile networks.

Yes, a good point.