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?
- [Hipsec] Segmentation within HIP Derek Fawcus
- Re: [Hipsec] Segmentation within HIP Tom Henderson
- Re: [Hipsec] Segmentation within HIP Robert Moskowitz
- Re: [Hipsec] Segmentation within HIP Robert Moskowitz
- Re: [Hipsec] Segmentation within HIP Derek Fawcus
- Re: [Hipsec] Segmentation within HIP Miika Komu
- Re: [Hipsec] Segmentation within HIP Robert Moskowitz
- Re: [Hipsec] Segmentation within HIP Robert Moskowitz
- Re: [Hipsec] Segmentation within HIP Gonzalo Camarillo
- Re: [Hipsec] Segmentation within HIP Robert Moskowitz