Re: [Hipsec] Segmentation within HIP

Robert Moskowitz <rgm@htt-consult.com> Tue, 29 March 2016 00:47 UTC

Return-Path: <rgm@htt-consult.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 9967E12D1DB for <hipsec@ietfa.amsl.com>; Mon, 28 Mar 2016 17:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 z5gILqVxDK2y for <hipsec@ietfa.amsl.com>; Mon, 28 Mar 2016 17:47:13 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 0F16112D195 for <hipsec@ietf.org>; Mon, 28 Mar 2016 17:47:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3B4A662250; Mon, 28 Mar 2016 20:47:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wefBI1yT2eew; Mon, 28 Mar 2016 20:47:06 -0400 (EDT)
Received: from lx120e.htt-consult.com (108.sub-70-199-4.myvzw.com [70.199.4.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 954246224F; Mon, 28 Mar 2016 20:47:04 -0400 (EDT)
To: Tom Henderson <tomhend@u.washington.edu>, dfawcus+lists-hipsec@employees.org
References: <alpine.LRH.2.01.1603251816260.6230@hymn04.u.washington.edu>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <56F9D086.1000105@htt-consult.com>
Date: Mon, 28 Mar 2016 20:47:02 -0400
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: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/A-cs9d3K-bBEBebWBeXIWel2-W4>
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 00:47:14 -0000

For starters i would look at the UDP NAT tunneling mechinism to provide it.

On 03/25/2016 09:16 PM, 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.
>
> - Tom
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>