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

Tero Kivinen <kivinen@iki.fi> Tue, 18 November 2008 20:56 UTC

Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D0F3A6B1C; Tue, 18 Nov 2008 12:56:32 -0800 (PST)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3B53A6B1C for <ipsec@core3.amsl.com>; Tue, 18 Nov 2008 12:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWEoUDMB60B2 for <ipsec@core3.amsl.com>; Tue, 18 Nov 2008 12:56:30 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BD2313A6A24 for <ipsec@ietf.org>; Tue, 18 Nov 2008 12:56:29 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mAIKuDQ0021714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 22:56:13 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAIKuCM1028005; Tue, 18 Nov 2008 22:56:12 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Message-ID: <18723.11244.118192.514010@fireball.kivinen.iki.fi>
Date: Tue, 18 Nov 2008 22:56:12 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com>
References: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 18 min
X-Total-Time: 20 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Jeff Bellamy <J.Bellamy@f5.com>, Amit Jain <a.jain@f5.com>, Ryan Korock <r.korock@f5.com>, James Goodwin <j.goodwin@f5.com>
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Yoav Nir writes:
> > -          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"

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.
-- 
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec