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

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

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Nov 2008 10:36:30 +0200

Hi James,

On Nov 18, 2008, at 9:38 AM, James Goodwin wrote:
> -          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.

At the previous IETF meeting, there was considerable opposition to the  
idea of making a "next-generation" ESP. Some participants did not want  
this extension to affect encrypted traffic.  For one reason, see below

> -          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.

It's not a lot of change to silicon, and the chip vendors should have  
no problem doing this for the next release. The problem is with  
already deployed devices such as routers and firewalls, that would not  
recognize this new protocol. Support can still be added with software  
or rulebase, but it does mean that such traffic may go on the slow  
path on intermediary devices. That is one reason why some participants  
don't want a "new ESP"

---

From: James Goodwin <[email-masked]>
Date: Tue, 18 Nov 2008 08:19:00 -0800

Hi Yoav,

Thanks very much for the response and context. Makes sense.

Yes, thinking about this more, understand why slow path (e.g. software) is not so bad if focus is only on unencrypted traffic. Still might argue that keeping some flexibility here (via flags octet) may save having to do another UDP wrapper in the future.

Cheers,
--James

From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, November 18, 2008 12:37 AM
To: James Goodwin
Cc: [email-masked]; Jeff Bellamy; Amit Jain; Ryan Korock
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt

Hi James,

At the previous IETF meeting, there was considerable opposition to the idea of making a "next-generation" ESP. Some participants did not want this extension to affect encrypted traffic.  For one reason, see below

It's not a lot of change to silicon, and the chip vendors should have no problem doing this for the next release. The problem is with already deployed devices such as routers and firewalls, that would not recognize this new protocol. Support can still be added with software or rulebase, but it does mean that such traffic may go on the slow path on intermediary devices. That is one reason why some participants don't want a "new ESP"

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Nov 2008 22:56:12 +0200

> path on intermediary devices. That is one reason why some participants  

One of the problems is that updating all the end nodes is EXTREMELY
costly. We can see that from IPv6. IPv6 was change in the IP that did
require updating all end-nodes and all intermediate nodes to work. NAT
on the other hand was solution to the same problem (running out of
IP-numbers) that only required updating/adding middle boxes. I assume
we all (unfortunately) can see which one of those was much faster to
spread out.

New esp or XESP or WESP do require end nodes and some middle boxes
(which want to do those deep inspections) updated. It does not require
all middle boxes which do not do anything for the ESP traffic to be
changed (i.e. routers do not need to be updated, so it is cheaper to
implement than IPv6). Anyways the cost is really in the end node
updates. It is really hard when you need to update few million end
node devices in the network in addition to updating few dozen deep
inspection boxes in the network.

Heuristics methods are something that can be implemented and taken in
use now, only box that needs to be updated is the middle box doing the
deep inspection, and that is not really a box requiring updating, but
a box that needs to be added, as there is no way to do that now...

People complain that heuristics are just probabilistics, but so is MAC
in the ESP header. It has probability of 2^96 that it will detect
errors in the packet.

If your deep inspection box checks the actual http url / and headers
in the http requiest, you are checking much more than 96 bits of the
packet, which means that random encrypted packet to pass that check
will have much smaller probability than the 1 out of 2^96 that message
authentication code in the ESP gives...

The ESP header has self-describing padding that will immediately give
you from 1 out of 2^16 up to 1 out of 2^64 probability that you can
detect packet is ESP NULL compared to the encrypted ESP packet (the
probability depends how many bytes of padding you have from 1 to 7 +
the padding length).

After that you can start checking other things like TCP header fields,
UDP port numbers etc (you might not be able to the TCP or UDP
checksums as if the packet went through NAT those checksums are wrong,
but on the other hand they only give 16 checked bits more). If the
packet happens to be tunnel mode IP packet you have full IP-header
inside, which has lots of bits you can check.

If you are talking about stateful filtering or deep inspection there
is lots of bits you are checking.

Also as each packet has SPI you can run the heuristics ones and then
store information about the SPI (i.e. encrypted data or ESP-NULL) to
that SPI.

I wrote this pseudocode for the heuristics methods earlier, but run
out of time to finish it (it still needs to be checked if it needs any
changes for IPv6, and write some most common stateful firewall
checking things (i.e. tcp flows, UDP flows etc)):

----------------------------------------------------------------------
Process IPv4 packet:
  * If IP protocol is ESP
       * Set SPI_offset to 0 bytes
       * Goto Process ESP
  * If IP protocol is UDP
       * Goto Process UDP
  * Continue Non-ESP processing

Process UDP:
  * If dst port != 4500
       * Continue Non-ESP processing
  * Set SPI_offset to 8 bytes
  * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000
       * Continue Non-ESP processing (pass IKE-packet)
  * If UDP_len == 1 and first byte is 0xff
       * Continue Non-ESP processing (pass NAT-Keepalive Packet)
  * Goto Process ESP

Process ESP:
  * If packet is fragment
       * Do full reassembly before processing
  * If IP_total_len < IP_hdr_len + SPI_offset + 4
       * Drop invalid packet
  * Load SPI from IP_hdr_len + SPI_offset
  * Find Dst IP + SPI from SPI cache
  * If SPI found
       * Load IV_len, ICV_len from cache
  * If SPI not found
       * Goto Autodetect ESP parameters (drop to slowpath)
  * Goto Check ESP-NULL packet

Check ESP-NULL packet:
  * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len
                 + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
       * Drop invalid packet
  * Load Protocol from IP_total_len - ICV_len - 1
  * Set Protocol_start_offset to
        IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no)
  * Do normal deep inspection on packet.

Autodetect ESP parameters
  * Goto Try standard algorithms
  * If Success
       * Goto Store SPI cache info
  * Goto Try 128bit algorithms
  * If Success
       * Goto Store SPI cache info
  * Goto Try 192bit algorithms
  * If Success
       * Goto Store SPI cache info
  * Goto Try 256bit algorithms
  * If Success
       * Goto Store SPI cache info
  * Goto Try 160bit algorithms
  * If Success
       * Goto Store SPI cache info
  # No idea how to test AUTH_DES_MAC and AUTH_KPDK_MD5 as they are
  # not defined anywhere
  * Drop invalid ESP-NULL packet

Store SPI cache info:
  * Store IV_len, ICV_len to SPI cache using Dst IP + SPI as key
  * Goto Check ESP-NULL packet

Try standard algorithms:
  # AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96,
  # AUTH_AES_CMAC_96
  * Set ICV_len to 12, IV_len to 0
  * Goto Check packet

Try 128bit algorithms:
  # AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128
  # AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC
  * Set ICV_len to 16, IV_len to 0
  * If verify padding fails
       * Return Failure
  * If verify packet fails
       * Goto Try GMAC
  * Return Success

Try GMAC:
  # AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC
  * Set IV_len to 8
  * If verify packet fails
       * Return Failure
  * Return Success

Try 192bit algorithms:
  # AUTH_HMAC_SHA2_384_192
  * Set ICV_len to 24, IV_len to 0
  * Goto Check packet

Try 256bit algorithms:
  # AUTH_HMAC_SHA2_512_256
  * Set ICV_len to 32, IV_len to 0
  * Goto Check packet

Try 160bit algorithms:
  # AUTH_HMAC_SHA1_160
  * Set ICV_len to 20, IV_len to 0
  * Goto Check packet

Check packet:
  * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len
       + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
       * Return Failure
  * If Verify padding fails
       * Return Failure
  * If Verify packet fails
       * Return Failure
  * Return Success

Verify padding:
  * Load Pad_len from IP_total_len - ICV_len - 2
  * Verify padding bytes at IP_total_len - ICV_len - 1 - Pad_len ..
               IP_total_len - ICV_len - 2 are 1, 2, ..., Pad_len
  * If Success
       * Return Success
  * Return Failure

Verify packet:
  # We can be quite conservative here, i.e. if packet looks any bit of
  # suspicious we can simply return failure, and wait for better
  # packet for heuristics, i.e. for example we might refuse
  # heuristic based on ICMP or UDP packets, and wait for the
  # TCP packet to existing connection, or any packet where we can do
  # bit more deeper inspection.
  # Normally this thing is only run once at startup, thus some packets
  # have already been lost and most likely all flow information
  # is already lost too, thus if we do not allow for example TCP
  # packets without existing flows to go through, we can simply wait
  # here either for TCP packet to existing flow or new TCP connection 
  # attempt.
  # Other case when this is called is when SA is rekeyed, i.e. gets
  # new SPI, but in that case the TCP flows etc are intact, thus
  # packets going through should match existing flows.
  * Load Protocol From IP_total_len - ICV_len - 1
  * If Protocol TCP
       * Goto Verify TCP
  * If Protocol UDP
       * Goto Verify UDP
  * If Protocol ICMP
       * Goto Verify ICMP
  # Other protocols can be added here as needed, most likely same
  # protocols as deep inspection does

Verify TCP:
  # Note, we cannot verify TCP checksum as it might be incorrect after
  # NAT.
  # Do normal deep TCP inspection here, but do not drop the packet on
  # failure, just return failure. On success update state and return
  # success.
  * If this is new TCP connection
       * Verify port numbers, window size, tcp header length, reserved
                     bits, flags, urgent pointer
       * If everything ok
	    * Add half open connection to TCP state table, return success
  * If this is existing TCP connection
       * Find src/dst IP/port from TCP flows table
       * Verify TCP header data
       * If everything ok
	    * Return Success
  * Return failure

Verify UDP:
  # Note, we cannot verify UDP checksum as it might be incorrect after
  # NAT.
  # Do normal deep UDP inspection here, but do not drop the packet on
  # failure, just return failure. On success update state and return
  # success.
  * Find src/dst IP/port from UDP flows table
  * If UDP connection is found
       * Verify packet based on the existing flow
       * If everything ok
	    * Return Success
  * If no UDP connection found
       * Verify new connection creation
       * If everything ok
	    * Return Success
  * Return failure

Verify ICMP:
  # Do similar ICMP verification here.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec