Re: [Hipsec] Segmentation within HIP

Tom Henderson <tomhend@u.washington.edu> Sat, 26 March 2016 01:20 UTC

Return-Path: <tomhend@u.washington.edu>
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 513E012D0C5 for <hipsec@ietfa.amsl.com>; Fri, 25 Mar 2016 18:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pZ8XmTTW7TzS for <hipsec@ietfa.amsl.com>; Fri, 25 Mar 2016 18:20:07 -0700 (PDT)
Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072ED12D09C for <hipsec@ietf.org>; Fri, 25 Mar 2016 18:20:06 -0700 (PDT)
Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u2Q1GTuM020090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2016 18:16:30 -0700
Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u2Q1GSKR023378; Fri, 25 Mar 2016 18:16:28 -0700
Received: from localhost (Unknown UID 10745@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u2Q1GQio023346; Fri, 25 Mar 2016 18:16:28 -0700
X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Fri, 25 Mar 2016 18:16:26 PDT
Date: Fri, 25 Mar 2016 18:16:26 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: dfawcus+lists-hipsec@employees.org
Message-ID: <alpine.LRH.2.01.1603251816260.6230@hymn04.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.26.11217
X-PMX-Server: mxout22.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0'
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/ISO2kMP50qwHF6UaPlPWhHhPRFQ>
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: Sat, 26 Mar 2016 01:20:08 -0000


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.

- Tom