Re: Segmentation within HIP
Robert Moskowitz <[email protected]>
| Newsgroups | gmane.ietf.hipsec,gmane.ietf.hip |
|---|---|
| Message-ID | <[email protected]> |
As I said, I am seeing this as part of a larger problem. And am working on some ideas. On 03/31/2016 11:12 AM, Gonzalo Camarillo wrote: > 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 >> > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec >