[Guy Harris <guy@xxxxxxxxxxxx>]

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?