Re: [Hipsec] Segmentation within HIP

Miika Komu <miika.komu@ericsson.com> Tue, 29 March 2016 07:50 UTC

Return-Path: <miika.komu@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 2C2E512D56E for <hipsec@ietfa.amsl.com>; Tue, 29 Mar 2016 00:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn4Aq-wepWXd for <hipsec@ietfa.amsl.com>; Tue, 29 Mar 2016 00:50:13 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E6712D0B6 for <hipsec@ietf.org>; Tue, 29 Mar 2016 00:50:12 -0700 (PDT)
X-AuditID: c1b4fb2d-f79c06d000005960-1d-56fa33b20c51
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.C4.22880.2B33AF65; Tue, 29 Mar 2016 09:50:10 +0200 (CEST)
Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 29 Mar 2016 09:50:07 +0200
To: Varjonen Samu <samu.varjonen@helsinki.fi>
References: <alpine.LRH.2.01.1603251816260.6230@hymn04.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <56FA33AF.3030507@ericsson.com>
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: <alpine.LRH.2.01.1603251816260.6230@hymn04.u.washington.edu>
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: <http://mailarchive.ietf.org/arch/msg/hipsec/XkMHlEdJsZ8GN4ovoGIz1RoxsQU>
Cc: hipsec@ietf.org
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: 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?