On May 11, 2010, at 2:12 PM, Jonathan wrote:
> I used the packet-ipsec.c to create two specific versions ofr ESP according 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?
