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
- [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-vis… Internet-Drafts
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… Yaron Sheffer
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… Michael Bowler
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… James Goodwin
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… James Goodwin
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… Yoav Nir
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… James Goodwin
- Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic… Tero Kivinen