Re: Segmentation within HIP

Hi,

when specified the HIP_DATA packets we noted the fragmentation problem
but simply advised against sending large packets, which sure is not a
great solution ;-)

https://tools.ietf.org/html/rfc6078#section-6

Cheers,

Gonzalo

On 26/03/2016 12:49 AM, 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
> 
> _______________________________________________
> Hipsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/hipsec
>