Subject: Re: [Hipsec] Segmentation within HIP

From: Tom Henderson <[email-masked]>
Date: Fri, 25 Mar 2016 18:16:26 -0700 (PDT)

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 28 Mar 2016 20:47:02 -0400

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

On 03/25/2016 09:16 PM, Tom Henderson wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 29 Mar 2016 07:50:28 +0100

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

Well,  UDP doesn't have any native segmentation / reassembly either;
so while it would help in getting across a NAT,  it'd not do anything
for fragments.

I could see someone digging out the scheme which was proposed a while
ago for UDP segmentation,  and casting it to fit within
draft-touch-tsvwg-udp-options-02.txt.

DF

---

From: Miika Komu <[email-masked]>
Date: Tue, 29 Mar 2016 10:50:07 +0300

Hi Samu,

On 03/26/2016 03:16 AM, Tom Henderson wrote:
>> 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.
>>
>> level segmentation/fragmentation,  rather than depend up IP level
>> fragmentation.
>>
>> 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.
>>
> 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?

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 29 Mar 2016 10:14:18 -0400

That is why I recommended you look at what Sue and I are developing for 
a session layer service on top of any transport that would provide 
this.  And of course it is always worthwhile to look at anything Joe 
Touch worked on....

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 29 Mar 2016 10:28:09 -0400

While working on 802.15.9, Tero and I discussed this.  IKEv1 allowed for 
REALLY BIG cert chains and had lots or problems even without NATs.  
IKEv2 is more restrictive such that we designed 15.9 worst case 
frag/reassem to be 24KB (more than enough per Tero):

"4.7 KMP Payload Size

As the MP Data layer allows a KMP payload to be fragmented up to 256 
fragments, this means that even if
the PHY is using 127 octet PSDUs (96 octets effective fragment size), 
this recommended practice can use
KMP payloads up to 24 576 octets."

If you design a UDP service that supports 32 fragments (5 bit counter), 
you can support payloads of ~15KB.