Re: Segmentation within HIP
Robert Moskowitz <[email protected]>
| Newsgroups | gmane.ietf.hipsec,gmane.ietf.hip |
|---|---|
| Message-ID | <[email protected]> |
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 > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec >