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 <[email protected]> wrote: > > 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? > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > -- "If men were angels, no government would be necessary." --Madison
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
