Re: [Hipsec] Segmentation within HIP

Miika Komu <> Tue, 29 March 2016 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C2E512D56E for <>; Tue, 29 Mar 2016 00:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pn4Aq-wepWXd for <>; Tue, 29 Mar 2016 00:50:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3E6712D0B6 for <>; Tue, 29 Mar 2016 00:50:12 -0700 (PDT)
X-AuditID: c1b4fb2d-f79c06d000005960-1d-56fa33b20c51
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 92.C4.22880.2B33AF65; Tue, 29 Mar 2016 09:50:10 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 29 Mar 2016 09:50:07 +0200
To: Varjonen Samu <>
References: <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
Date: Tue, 29 Mar 2016 10:50:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050409050201040300020804"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdRnez8a8wg1yLqYsmM1vc+DmD3YHJ o3/lfnaPJUt+MgUwRXHZpKTmZJalFunbJXBlPH24ma1gv33Fs+kP2RsYL1t1MXJySAiYSMy5 vJIZwhaTuHBvPRuILSRwhFFiQZ9ZFyMXkL2aUaLx1UMWkISwgK7E7QlTwWwRILv9YhMLRIOH xNzLf5m6GDk4mAVEJbbPqgIJswloSay6cx1sPr+ApMSGht1gNq+AtsT5B3MYQWwWAVWJzpkn wcaICkRIPJl7khGiRlDi5MwnYHFOAU+J/ftWM4LcwyzQzSix/M0rFpBdQgIqEhePBU9gFJyF pGUWsjKQBLOArcSdubuZIWxtiWULX0PZ1hIzfh1kg7AVJaZ0P2SHsE0lXh/9yAhhG0ssW/eX bQEjxypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwBg5uOW37g7G1a8dDzEKcDAq8fAmrPwZ JsSaWFZcmXuIUQVozqMNqy8wSrHk5eelKonwVon/ChPiTUmsrEotyo8vKs1JLT7EKM3BoiTO y/bpcpiQQHpiSWp2ampBahFMlomDU6qB0UdMSk1mEfPrJVFK85pXbNIvK1Nnt63d//GNb/yN 9cu8tl0ou5zPbfQxk1Fz1YEPi1XCgpP7lh374Pp5h+DUzJ/STncOXrCQE0n7ytniGbNFKKjm 8YZHG16edH6j2mCQUHt173J/gZumxjX63GEKZof91D+IWzguba3eoP9/588+A3tbtpYsJZbi jERDLeai4kQA8YOGG5kCAAA=
Archived-At: <>
Subject: Re: [Hipsec] Segmentation within HIP
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Mar 2016 07:50:15 -0000

Hi Samu,

On 03/26/2016 03:16 AM, Tom Henderson wrote:
> On 03/25/2016 03:49 PM, 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
> Hi Derek, I don't remember the details, but in the early days of HIP,
> it was decided to avoid the burden of supporting fragmentation.  I
> guess I'd prefer to see some evidence that HIP messages are being
> fragmented in the wild before starting a work effort to add support.

do you recall how long a typical X.509 certificate can get?