Wireshark mailing list archives
Re: compiling multiple versions of ESP
From: Jonathan <jshufelt () gmail com>
Date: Wed, 12 May 2010 13:29:49 -0700
Actually, its ESPv1 and ESPv3. I am working on other block cipher modes of operation that are not currently in openssl. I just find it strange that only one ESP dissector as a plug in can be compiled at a time. --Jonathan On Wed, May 12, 2010 at 11:47 AM, Guy Harris <guy () alum mit edu> wrote:
On May 11, 2010, at 2:12 PM, Jonathan wrote:I used the packet-ipsec.c to create two specific versions ofr ESPaccording to rfc 2406 and ESPv3 according to rfc 4303. RFC 4303 says:7. Differences from RFC 2406 This document differs from RFC 2406 in a number of significant ways. o Confidentiality-only service -- now a MAY, not a MUST. o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. o Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. o Payload data -- broadened model to accommodate combined mode algorithms. o Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field. o Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59) o ICV -- broadened model to accommodate combined mode algorithms. o Algorithms -- Added combined confidentiality mode algorithms. o Moved references to mandatory algorithms to a separate document. o Inbound and Outbound packet processing -- there are now two paths: (1) separate confidentiality and integrity algorithms and (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing. 8. Backward-Compatibility Considerations There is no version number in ESP and no mechanism enabling IPsec peers to discover or negotiate which version of ESP each is using or should use. This section discusses consequent backward-compatibility issues. First, if none of the new features available in ESP v3 are employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting packet format may differ from the ESP v2 spec. However, a peer who implements only ESP v2 would never negotiate such an algorithm, as they are defined for use only in the ESP v3 context. Extended Sequence Number (ESN) negotiation is supported by IKE v2 and has been addressed for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI). In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC): - arbitrary padding after the end of an IP packet - a discard convention using Next Header = 59 The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3. The second feature allows a sender to send a payload that is an arbitrary string of bytes that do not necessarily constitute a well- formed IP packet, inside of a tunnel, for TFC purposes. It is an open question as to what an ESP v2 receiver will do when the Next Header field in an ESP packet contains the value "59". It might discard the packet when it finds an ill-formed IP header, and log this event, but it certainly ought not to crash, because such behavior would constitute a DoS vulnerability relative to traffic received from authenticated peers. Thus this feature is an optimization that an ESP v3 sender can make use of irrespective of whether a receiver implements ESP v2 or ESP v3.so I'm not sure why there would need to be separate dissectors for ESPv2 and ESPv3. Why not just have a single dissector handle both? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
-- "If men were angels, no government would be necessary." --Madison
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- compiling multiple versions of ESP Jonathan (May 11)
- Re: compiling multiple versions of ESP Guy Harris (May 12)
- Re: compiling multiple versions of ESP Jonathan (May 12)
- Re: compiling multiple versions of ESP Guy Harris (May 12)