[IPsec] Reauthentication extension for IKEv2

[Tero Kivinen <kivinen at iki.fi>]

David Wierbowski writes:
> 
> >> But the real problem are application session: They might break during
> >> these communication interrupts, and are guaranteed to break if the
> >> INTERNAL_ADDRESS changes.
> >
> >I agree, thats why I think the way you presented there where you first
> >remove the IKE SA and then start it over so you get the same address
> >is the only one that really works. In most cases for remote
> >access cases you have only one IPsec SA so creating new IKE SA and
> >that IPsec SA is fast and should not disturb normal TCP/IP flows
> >(unless your operating system does stupid things, like destroy all
> >TCP/IP flows when you do the recreationg of the IKE SA).
> 
> Are we clarifying the IKEv2 clarifications now?

No, I think the plan was to have new protocol. 

> RFC 4718 states:
> 
>    IKEv2 does not have any special support for reauthentication.
>    Reauthentication is done by creating a new IKE_SA from scratch (using
>    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
>    payloads), creating new CHILD_SAs within the new IKE_SA (without
>    REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
>    deletes the old CHILD_SAs as well).
> 
> The suggestion above contradicts 4718.

That way of reauFrom ipsec-bounces at ietf.org  Wed Sep 17 03:35:48 2008
Return-Path: <ipsec-bounces at ietf.org>
X-Original-To: ipsec-archive at megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 452B228C10C;
	Wed, 17 Sep 2008 03:35:48 -0700 (PDT)
X-Original-To: ipsec at core3.amsl.com
Delivered-To: ipsec at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DAF0628C10C
	for <ipsec at core3.amsl.com>; Wed, 17 Sep 2008 03:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 
	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 PLp7TFHHTl0J for <ipsec at core3.amsl.com>;
	Wed, 17 Sep 2008 03:35:47 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi
	[IPv6:2001:1bc8:100d::2])
	by core3.amsl.com (Postfix) with ESMTP id E728D3A659B
	for <ipsec at ietf.org>; Wed, 17 Sep 2008 03:35:38 -0700 (PDT)
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 m8HAZm8B014490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Sep 2008 13:35:48 +0300 (EEST)
Received: (from kivinen at localhost)
	by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8HAZkad020817;
	Wed, 17 Sep 2008 13:35:46 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen at iki.fi using -f
MIME-Version: 1.0
Message-ID: <18640.56706.660550.115329 at fireball.kivinen.iki.fi>
Date: Wed, 17 Sep 2008 13:35:46 +0300
From: Tero Kivinen <kivinen at iki.fi>
To: David Wierbowski <wierbows at us.ibm.com>
In-Reply-To: <OF0080022F.AF1F3D97-ON852574C6.004DC973-852574C6.004E0922 at us.ibm.com>
References: <OF0080022F.AF1F3D97-ON852574C6.004DC973-852574C6.004E0922 at us.ibm.com>
X-Mailer: VM 7.19 under Emacs 22.1.1
X-Edit-Time: 15 min
X-Total-Time: 22 min
Cc: ipsec at ietf.org
Subject: [IPsec]   Reauthentication extension for IKEv2
X-BeenThere: ipsec at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec at ietf.org>
List-Help: <mailto:ipsec-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces at ietf.org
Errors-To: ipsec-bounces at ietf.org

David Wierbowski writes:
> 
> >> But the real problem are application session: They might break during
> >> these communication interrupts, and are guaranteed to break if the
> >> INTERNAL_ADDRESS changes.
> >
> >I agree, thats why I think the way you presented there where you first
> >remove the IKE SA and then start it over so you get the same address
> >is the only one that really works. In most cases for remote
> >access cases you have only one IPsec SA so creating new IKE SA and
> >that IPsec SA is fast and should not disturb normal TCP/IP flows
> >(unless your operating system does stupid things, like destroy all
> >TCP/IP flows when you do the recreationg of the IKE SA).
> 
> Are we clarifying the IKEv2 clarifications now?

No, I think the plan was to have new protocol. 

> RFC 4718 states:
> 
>    IKEv2 does not have any special support for reauthentication.
>    Reauthentication is done by creating a new IKE_SA from scratch (using
>    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
>    payloads), creating new CHILD_SAs within the new IKE_SA (without
>    REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
>    deletes the old CHILD_SAs as well).
> 
> The suggestion above contradicts 4718.

That way of reauthenticathentication is good if you do not have internal ip
allocated from the gateway. If you do have internal ip-address
allocated from the gateway, then that will most likely fail, as unless
the server implementation knows how about reauthentications it will
not allow giving out same IP-address to some other IKE SA. 

> It seems as if the best resolution
> would be to add real support for reauthentication.

If we add new reauthentication protocol that would need to be separate
document not part of IKEv2bis. If we simply clarify how to do the
reauthentication without adding new protocols that can most likely be
added to the IKEv2bis.

We could for example add following paragraph to explain
reauthentication (after the paragraph you quoted):

   This method of reauthentication can introduce problems when used in
   combiation with configuration payloads (i.e. when client has
   INTERNAL_ADDRESS allocated from the gateway) unless the server
   implementation allows duplicate INTERNAL_ADDRESSs to be allocated
   to new IKE SA even when it is still in use with the old IKE SA. The
   server implementation should check that such duplicate addresses
   are only allowed when the new IKE SA connection comes from the same
   IP address and port, and has same configuration parameters than the
   existing IKE SA (i.e. requests same IP-address that is already in
   use) and when the authenticated identity of the both IKE SAs is
   exactly same. The server can also move the old IKE SA to degraded
   state, where it refuses to create more IPsec SAs (returning
   NO_ADDITIONAL_SAS error instead).

(I noticed that mentioning INITIAL_CONTACT notification is not needed,
as if there is INITIAL_CONTACT in the new IKE SA then the old IKE SA
will be removed when processing that INITIAL_CONTACT notification,
thus the IP address will be free). 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


tion is good if you do not have internal ip
allocated from the gateway. If you do have internal ip-address
allocated from the gateway, then that will most likely fail, as unless
the server implementation knows how about reauthentications it will
not allow giving out same IP-address to some other IKE SA. 

> It seems as if the best resolution
> would be to add real support for reauthentication.

If we add new reauthentication protocol that would need to be separate
document not part of IKEv2bis. If we simply clarify how to do the
reauthentication without adding new protocols that can most likely be
added to the IKEv2bis.

We could for example add following paragraph to explain
reauthentication (after the paragraph you quoted):

   This method of reauthentication can introduce problems when used in
   combiation with configuration payloads (i.e. when client has
   INTERNAL_ADDRESS allocated from the gateway) unless the server
   implementation allows duplicate INTERNAL_ADDRESSs to be allocated
   to new IKE SA even when it is still in use with the old IKE SA. The
   server implementation should check that such duplicate addresses
   are only allowed when the new IKE SA connection comes from the same
   IP address and port, and has same configuration parameters than the
   existing IKE SA (i.e. requests same IP-address that is already in
   use) and when the authenticated identity of the both IKE SAs is
   exactly same. The server can also move the old IKE SA to degraded
   state, where it refuses to create more IPsec SAs (returning
   NO_ADDITIONAL_SAS error instead).

(I noticed that mentioning INITIAL_CONTACT notification is not needed,
as if there is INITIAL_CONTACT in the new IKE SA then the old IKE SA
will be removed when processing that INITIAL_CONTACT notification,
thus the IP address will be free). 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec