[IPsec] Comments about draft-ietf-ipsecme-ipsec-ha-00

Tero Kivinen <kivinen@iki.fi> Sun, 21 March 2010 22:04 UTC

Return-Path: <kivinen@iki.fi>
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 A228D3A6824 for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 15:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-1.842, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 FQpH1JGHSngn for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 15:04:30 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 753403A677D for <ipsec@ietf.org>; Sun, 21 Mar 2010 15:04:30 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o2LM4ej5022982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 00:04:40 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2LM4dfL027341; Mon, 22 Mar 2010 00:04:39 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19366.38903.768745.232444@fireball.kivinen.iki.fi>
Date: Mon, 22 Mar 2010 00:04:39 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ynir@checkpoint.com, ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 17 min
Subject: [IPsec] Comments about draft-ietf-ipsecme-ipsec-ha-00
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/mail-archive/web/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>
X-List-Received-Date: Sun, 21 Mar 2010 22:04:31 -0000

I was quickly browsing this document and here is some quick comments
to it:

In section 3.2 it is only talking about counters, but for IKE SA the
other MUST also be able to retransmit previous message in case it was
lost. So it is not enough to transmit only the Message-ID counters
(inbound window and outbound message), but also the actual packets
associated with each message ID (for outbound case). If devices have
window larger than one, then the outbound request window could be
large, so several packets per IKE SA needs to be kept. Request packets
can be forgotten when reply is received, but replies cannot be
forgotten as there is no way to know whether other end received the
reply or not.

Good thing is that the outbound messages are static after they are
sent, thus they only need to be transmitted over the synch channel
once.

Also in case MOBIKE is used, that will add even more state to the SAs,
as the active peer addresses needs to be stored. Most likely there is
no need to store the mobike process data itself, as the mobike process
that was just ongoing when failure happened, can be rerun after
failover.

In section 3.4 there is text saying:

>   o  It requires multiple parallel SAs, which the peer has no use for.
>      Section 2.8 or [RFC4306] specifically allows this, but some
>      implementation might have a policy against long term maintenance
>      of redundant SAs.
   
This is not only allowed, it is MUST feature of RFC4301 (section 4.1
says:

   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these

So even when RFC4306 says it is allowed, it is mandatory feature in
IPsec architecture, thus I do not think it really matters if some
implementations decide to make policy rules against it as they surely
will have way to turn those policy rules off to be able to be RFC4301
complient.

Also I think the other two "shortcomings" are not really relevenat
here. The firewall or deep inspection engine actiong on the load
balancing devices, must be able to cope with the problem anyways. Also
IPsec does not have return packets, thus where those imaginary return
packets come in does not matter.
-- 
kivinen@iki.fi