[Hipsec] Segmentation within HIP
Derek Fawcus <dfawcus+lists-hipsec@employees.org> Fri, 25 March 2016 22:49 UTC
Return-Path: <dfawcus@employees.org>
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 04DBD12D19B for <hipsec@ietfa.amsl.com>; Fri, 25 Mar 2016 15:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org
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 U3uu_vcPB8OB for <hipsec@ietfa.amsl.com>; Fri, 25 Mar 2016 15:49:22 -0700 (PDT)
Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442BB12D0AD for <hipsec@ietf.org>; Fri, 25 Mar 2016 15:49:22 -0700 (PDT)
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AED97D7893 for <hipsec@ietf.org>; Fri, 25 Mar 2016 15:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:mime-version:content-type; s=selector1; bh=aWMnOrY9LSMwlJuw1CGgmFZFkBQ=; b=S7M70eHyjSAutfTjFv0PHvkKlwln MsJXXVWEsvRka+FCOS21mIRJ5k0nZToqhzcDl98QL2vNKb35e6HXMVPljNhjo7kv c7CsKpV+DOp8BHbYP3pJ/A4jYjvdJhfly1l/4/W3m5VgFzadIusjP20IZ4ybxjS+ 4oqiFRcscQtuwYA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:mime-version:content-type; q=dns; s= selector1; b=AxI/Q8UCCtLCYrA/oWMdtV7s+vozz9udMwA2NkLFAFdxEW3qFXk e7O1lFP8IGDyA021mc+gsgREy+jmYk4chgRcZv340Yls0hwQfqZqXRnwz8HPiAx0 htt9qGBy16aTciAmazeajW2f8GkcFzjbvr/srotpODwtrehrErun3Elk=
Received: by cowbell.employees.org (Postfix, from userid 1736) id A1405D7884; Fri, 25 Mar 2016 15:49:21 -0700 (PDT)
Date: Fri, 25 Mar 2016 23:49:21 +0100
From: Derek Fawcus <dfawcus+lists-hipsec@employees.org>
To: hipsec@ietf.org
Message-ID: <20160325224921.GA75376@cowbell.employees.org>
Mail-Followup-To: hipsec@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/Vmyoc_h0RHexufbVHF1Z2fSnuNc>
Subject: [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: Fri, 25 Mar 2016 22:49:24 -0000
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] 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