On Friday 8th Feb 2013, Karl Auer wrote, in part: > Do you mean that the ESP header must be the first item in the > fragmentable part of the first fragment? Or that the ESP header > must be (at least partly) in the non-fragmentable part of the > first fragment?
I can't lex your question, so please forgive me for starting from first principles. :-) As the name Encapsulating Security Payload (ESP) implies, ESP *encapsulates* other information, (seeks to) protect the encapsulated information, and ESP is always a terminating payload. Put another way, while ESP might contain something else (e.g. an encrypted blob that if successfully decrypted becomes a TCP header and TCP data segment), ESP is itself always the last payload in the original on-the-wire packet. In the general case, the ESP is encrypted, so the only parseable object is the SPI, which consists of the first few bytes of the ESP. The SPI is used to demux different ESP-protected sessions so that a legitimate recipient can learn which cryptographic keys/algorithms/modes to apply to the ESP in order to retrieve the protected information. While various techniques for parsing an ESP that might not be encrypted have been proposed, none seems completely (i.e. 100.00%) reliable. Separately, the proposed WESP extension appears to have zero implementations, and no support in any router/middlebox/firewall/NAT device. So WESP turns out to be irrelevant for this discussion. > If the latter, that's a new kind of animal. Not at all. ESP isn't an optional intermediate header. ESP always is an optional terminating payload, optional in the sense that a packet could contain other terminating payloads (e.g. UDP, TCP, SCTP, ICMP). > At present, a header is either completely in the > non-fragmentable part or completely in the fragment able > part. Permitting a header to straddle the fragment header > seems odd, It is already the normal case for ESP. At present, ESP might be partly in a first fragment, split between two fragments, or entirely in a non-first fragment. > and I can't immediately see how you could do it without > changing the fragment header definition, either. In turn, your confusion puzzles me. Does the above explanation help at all ? Cheers, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
