[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new ESP spec (bigger message)
Dan,
+=========+ > > ***We have a potential IPv6 alignment problem
| ver ... | > > here, that may have
| ESP | ...
| src ... | >
| | > This isn't a real problem for IPv6. The reason
| | > for the 8-byte alignment drive in IPv6 was to make
| | > fast-path processing faster. (Those of us with
| dst ... | > UltraSPARC appreciate this.) Since ESP is already
| | > beating down the slow path, this isn't as huge of
| | > a deal as one might think at first. Also, a
| | > properly formed IPv6 datagram will be 8-byte
+=========+ > aligned once you strip out the ESP cruft after
| SPI | > decryption.
| IV ... |
| | I was under the impression that the 8-byte alignment
+---------+ drive was to make processing not incur a lot of
| ver ... | address alignment faults when processing IPv6
| TCP | packets. I also heard a desire that IPsec be
| src ... | "friendly" to both hardware and software based
| | algorithms. If one uses a software algorithm that
| | decrypts in place, and have an IPv6 packet that
| | begins as shown to the left, then the tunneled IPv6
| dst ... | header, etc., is not aligned, relative to the outer
| | one.
| |
| | One argument for not needing alignment is that
+---------+ decryption in place won't be common, as a hardware
| TCP Hdr | decryption will "copy" the packet and can be made to
| Data | do realignment in the process.
| +----+
| |n|IP| Another is that IPv6 header alignment on 64-bit
+----+----+ boundaries is not a "requirement", just a "guide
line".
I do not see any justification why AH and ESP should differ in their
requirements to preserve alignment across their headers.
Comments anyone?
Charlie
Follow-Ups: