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 [email protected] https://www.ietf.org/mailman/listinfo/hipsec
