Re: [Hipsec] Segmentation within HIP

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 31 March 2016 15:13 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62F912D0D8 for <hipsec@ietfa.amsl.com>; Thu, 31 Mar 2016 08:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.221
X-Spam-Level:
X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZuFfKWfj8Df for <hipsec@ietfa.amsl.com>; Thu, 31 Mar 2016 08:13:58 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FDA12D199 for <hipsec@ietf.org>; Thu, 31 Mar 2016 08:13:57 -0700 (PDT)
X-AuditID: c1b4fb30-f79246d00000788a-84-56fd3eb3271c
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.D8.30858.3BE3DF65; Thu, 31 Mar 2016 17:13:56 +0200 (CEST)
Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 17:12:01 +0200
To: <hipsec@ietf.org>
References: <20160325224921.GA75376@cowbell.employees.org>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <56FD3E40.9080200@ericsson.com>
Date: Thu, 31 Mar 2016 18:12:00 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160325224921.GA75376@cowbell.employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2J7iO4Wu79hBhsWcFlMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGd/7Z7MU9AtUHJy8kbGB8TxPFyMnh4SAicSEU3cZIWwxiQv3 1rN1MXJxCAkcYZQ4MeksK0hCSGAto8SuPiEQW1hAV+L2hKksILaIgKjElA+nmSFqrCRa/30C G8QmYCGx5dZ9sBpeAW2J7svH2EBsFgFViQWvOthBbFGBGInj784xQtQISpyc+QSsnlPAWuLl spdgNrOAgcSRRXNYIWx5ie1v50Dt0pZY/qyFZQKjwCwk7bOQtMxC0rKAkXkVo2hxanFSbrqR kV5qUWZycXF+nl5easkmRmAIHtzy22AH48vnjocYBTgYlXh4F7T8CRNiTSwrrsw9xCjBwawk wvvY9m+YEG9KYmVValF+fFFpTmrxIUZpDhYlcV7WT5fDhATSE0tSs1NTC1KLYLJMHJxSDYzz b+cr8f98wDzLaJPhusczQ0My+fQeLinxKXlhUvT142H9qxuU1Pd9N/9xVj/79HaFOfetZ/lu Nkz77rdsv8ujzG1+upYvtpesnT2/uOLaikeMGlJ1d/V7Xx+oqUma1pWSFPdJvpvJI7J6HdNE OYUlxi69r60OvnjH0mh3dLn8PUtz2RqZsldKLMUZiYZazEXFiQA+rkThPQIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/XiqlcW_Z6tAui4BOlbVmdomX7ZM>
Subject: Re: [Hipsec] Segmentation within HIP
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
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/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 31 Mar 2016 15:14:00 -0000

Hi,

when specified the HIP_DATA packets we noted the fragmentation problem
but simply advised against sending large packets, which sure is not a
great solution ;-)

https://tools.ietf.org/html/rfc6078#section-6

Cheers,

Gonzalo

On 26/03/2016 12:49 AM, Derek Fawcus wrote:
> Recently I've been working on middlebox s/w:  Firewalls and NAT.
> 
> One thing this has brought home to me is just how unreliable
> fragmentation is on the current Internet.  NAT will often
> simply break it (such that they can not be reassembled) or
> just discard them,  and firewalls are often set up to block them.
> 
> As such,  almost every protocol now would seem to need protocol
> level segmentation/fragmentation,  rather than depend up IP
> level fragmentation.
> 
> It struck me that it should be quite simple to extend HIP to
> support such.
> 
> 1) Add a Controls bit which advertises that the sender supports
>    segmentation.
> 2) Define a new parameter,  numbered 1 such that it is first in
>    the parameters,  and is critical.
>    Within the parameter have a seqno/identifier, offset and
>    more segments / final segment bit, possibly also a total
>    size field.  Define some simple reassembly rules,  similar
>    to those for IP fragments, such that one could reassemble
>    a HIP packet larger than 2008 bytes if desired (how big?).
> 3) Possibly also define a none critical parameter within the
>    non signed,  non MACed range which advertises the max size
>    packet the sender is willing to reassemble.  In fact I guess
>    this might remove the need to use a Controls bit,  since it
>    would imply the sender can reassemble.
> 
> Then have a rule that once one party has seen the other party
> advertise the segmentation capability within the current BEX
> session, it is free to make use of segmentation towards that peer.
> 
> Thoughts?
> 
> DF
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>