Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt

From: James Goodwin <[email-masked]>
Date: Mon, 17 Nov 2008 23:47:00 -0800

Hi again,

One additional note. Forwarding some food for thought on behalf of a colleague.

We are certainly in support of the traffic visibility draft presented. Straight-forward solution and will be easy for our traffic management appliances to act as intermediate devices to view and act on the unencrypted data payload.

Below is simply an additional idea that may have been explored already (or may not be feasible for compatibility reasons). Thanks to Amit for spending some time putting these thoughts down.

Cheers,
--James

The alternative is to use the reserve space of SPI (0 - 255) to indicate the ESP integrity only mode. (Something similar to what is proposed in the UDP encapsulation case in the draft) The way it may work is:

1: Reserved SPI value of 0x00000001 is used to indicate the presence of integrity mode.
2: There is no change in the ESP header for the integrity only mode. This'll allow the non-compliant devices to just treat the integrity only mode as normal ESP/IPSEC traffic.
3: The compliant device treats the packet with SPI value of 0x00000001 as the ESP integrity mode packets only.
4: The real/effective SPI of ESP integrity mode packets are part of payload. (Just like IV is in case of some encryption methods). It may be first four bytes of the payload.

So if the sender of IPSEC packet is supports ESP integrity mode, it puts the SPI value of 0x00000001 in the SPI fields of ESP header, prepares the other fields just like it would normally and then puts the actual SPI in the first four bytes of payload. (Since the payload is not encrypted, the SPI can be retrieved at the destination)

ð  The intermediate devices, which understands ESP integrity only mode; looks into payload and apply traffic management functionality.
ð  The intermediate devices, which do not understands ESP integrity only mode, this packet will look like just like any other ESP packet and they can treat this as the normal ESP traffic.
ð  The receiver upon receiving this packet extracts the real or effective SPI from payload and applies the IPSEC processing. Since the payload is not encrypted, SPI can be retrieved at receiver.

In this scheme, both the sender and receiver need to be modified to support ESP integrity only mode. But the intermediate devices need not to be modified.
This'll lower the deployment efforts for the ESP integrity only mode and help facilitate the use of it.

From: James Goodwin
Sent: Monday, November 17, 2008 11:39 PM
To: [email-masked]'
Cc: Jeff Bellamy; Ryan Korock; Amit Jain
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt

Hi,

As a follow-up to other comments on the Wrapped ESP for Traffic Visibility draft, I'd like to add a quick note.

I have reviewed this IETF draft, and does appear to be a reasonable solution to the problem of intermediate devices determining on a per-packet basis whether the ESP data payload is encrypted or clear-text (for network monitoring and deep packet inspection). It overcomes the original problem of ESP not providing an integrity-only flag.

This, IMHO, is a cleaner solution than a heuristics based approach (pattern matching to determine if payload is encrypted). The data in the defined XESP will allow our traffic management OS (TMOS) to easily determine whether the data payload is encrypted, inspect, and apply traffic management rules based on content in the data payload. This will be possible with fairly straight-forward software changes (and may be supported to some degree via built-in rules language - no code changes necessary).

A couple questions/concerns:

-          Why not include an "integrity-only" bit in the header (flags octet) so that the wrapper may be used to handle both integrity-only and encryption + integrity modes for ESP? I believe Yaron has also asked this question.

-          How much change to silicon (cost to chip vendors) is required to support the additional XESP header and new protocol number? This must be widely supported by IPSec silicon vendors for this proposal to succeed.

Thanks,
--James

James Goodwin | Sr. Director, Product Development

F5 Networks

t: 408.273.4821

www.f5.com<http://www.f5.com>

c: 408.421.6956

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec