Subject: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Nov 2014 12:06:34 -0800

<chair hats on>

Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA setup in cases where VPN gateways have multiple interfaces and want to establish different SAs on the different interfaces without having to repeat the IKE authentication. Instead, they could clone a single IKE SA multiple times, and then move it to different interfaces using MOBIKE.

If you agree with the need to standardize this usage, and believe that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 27 Nov 2014 15:56:58 +0300

Hi all,

as a co-author of the draft I (obviously) support its adoption.

I think that the mechanism it describes is useful and could be used
as a building block for several solutions. For example,
it can be used in load-sharing scenario when there are
some gateways with different IP addresses, that share
the same credentials. If client established IKE SA with
any of them then the SA could be cloned and transfered
to other nodes of this cluster without reauthentication,
and the traffic from client then could be balanced
among those gateways.

Regards,
Valery Smyslov.

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "IPsecME WG" <[email-masked]>
Sent: Tuesday, November 25, 2014 11:06 PM
Subject: [IPsec] Survey for WG interest in 
adoptingdraft-mglt-ipsecme-clone-ike-sa

> <chair hats on>
>
> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA 
> setup in cases where VPN gateways have multiple interfaces and want to 
> establish different SAs on the different interfaces without having to 
> repeat the IKE authentication. Instead, they could clone a single IKE SA 
> multiple times, and then move it to different interfaces using MOBIKE.
>
> If you agree with the need to standardize this usage, and believe that 
> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for 
> that standardization, and are willing to review and contribute text to the 
> document if it is adopted by the WG, please say so on the list. This WG 
> has a history of adopting documents but then not having enough reviewers 
> for us to feel confident that we are making a good standard, so we need to 
> see a reasonable number of actively interested people before we adopt the 
> document. If it is not adopted, the authors can ask for it to be published 
> as an RFC through individual submission or by the Independent Submissions 
> Editor.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 Nov 2014 15:00:09 +0200

<hat on: RFC 5723 co-author>

Hi Valery,

Have you looked at using session resumption (RFC 5723) for this, instead 
of coming up with a new mechanism?

Thanks,
	Yaron

On 11/27/2014 02:56 PM, Valery Smyslov wrote:
> ----- Original Message ----- From: "Paul Hoffman" <[email-masked]>
>> repeat the IKE authentication. Instead, they could clone a single IKE
>> SA multiple times, and then move it to different interfaces using MOBIKE.
>>
>> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place
>> for that standardization, and are willing to review and contribute
>> text to the document if it is adopted by the WG, please say so on the
>> list. This WG has a history of adopting documents but then not having
>> enough reviewers for us to feel confident that we are making a good
>> standard, so we need to see a reasonable number of actively interested
>> people before we adopt the document. If it is not adopted, the authors
>> can ask for it to be published as an RFC through individual submission
>> or by the Independent Submissions Editor.
>>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 27 Nov 2014 17:26:04 +0300

Hi Yaron,

one disadvantage is that client in this case
must know all the cluster's addresses beforehand.
It is better when cluster itself makes decision
when and where to move any particular client
and client plays only passive role.

And resumption tickets are intended to
restore IKE SA with that particular gate, not to clone it.
So tickets are one-time use. I think ticket management
can become too complex if we want to allow
client to have multiple tickets and to use them
in any order with any of cluster member.

Regards,
Valery.

----- Original Message ----- 
From: "Yaron Sheffer" <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>; "IPsecME WG" <[email-masked]>
Sent: Thursday, November 27, 2014 4:00 PM
Subject: Re: [IPsec] Survey for WG interest in 
adoptingdraft-mglt-ipsecme-clone-ike-sa

---

From: Paul Wouters 🔓 <[email-masked]>
Date: Thu, 27 Nov 2014 11:22:11 -0500 (EST)

> and the traffic from client then could be balanced

That would run into replay protection problems, just like if you copy
all kernel IPsec state between machines. And I believe load sharing
when properly done should be invisible to client side and not need
special support.

>> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA setup 
>> in cases where VPN gateways have multiple interfaces and want to establish 
>> different SAs on the different interfaces without having to repeat the IKE 
>> authentication. Instead, they could clone a single IKE SA multiple times, 
>> and then move it to different interfaces using MOBIKE.
>> 
>> document if it is adopted by the WG, please say so on the list.

I am interested in the problem, but have bad feelings about throwing
around IKE states from two peers to another peer, which this
mechanism seems to leave open. For instance, I would much rather see
some informational exchange method or create child sa method using the
existing IKE SA for conveying this information and somehow creatie the
additional new Child SA.

Throwing around private keys or computed shared secrets to multiple
peers worry me.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 28 Nov 2014 14:43:52 +0300

Hi Paul,

> all kernel IPsec state between machines.

Why? If I copy only IKE SA and then create IPsec SAs
on new gateway there will be no need to copy
kernel IPsec states and deal with replay protection.

> And I believe load sharing

I agree with you in general, but I don't think it is
always feasible in case of IPsec without some
cooperation with client (or you will really
need to share kernel IPsec state between
cluster nodes).

>>> for that standardization, and are willing to review and contribute text 
>>> to the document if it is adopted by the WG, please say so on the list.
>

Isn't this similar to what resumption does?

> Throwing around private keys or computed shared secrets to multiple

It is often unavoidable in case of clusters.
And of course all due precautions need to be taken
in this case to minimize chances to leak information.

Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Nov 2014 15:14:20 +0200

Paul Hoffman writes:
> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE
> SA setup in cases where VPN gateways have multiple interfaces and
> want to establish different SAs on the different interfaces without
> having to repeat the IKE authentication. Instead, they could clone a
> single IKE SA multiple times, and then move it to different
> interfaces using MOBIKE. 
> 
> If you agree with the need to standardize this usage, and believe
> that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting
> place for that standardization, and are willing to review and
> contribute text to the document if it is adopted by the WG, please
> say so on the list.

I support adopting this document for WG draft, or just go forward as
individual submission. I have already reviewed this draft, and I think
it is mostly ready already, so we could even start WG or IETF last
call almost immediately.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Nov 2014 15:50:43 +0200

> when properly done should be invisible to client side and not need

Actually I tihnk the idea is to get rid of the replay protection
issues. In normal case if you just copy all IKE and IPsec state
between the servers, then you need to make sure you also copy all
replay data. If you clone the IKE SA, move the cloned IKE SA to new
IP-address (and new load sharing server in the cluster), and then
create the IPsec Child SAs there, then each of the replay data is only
located in the server you are talking to, and there is no need to move
replay data between the cluster members.

If the load sharing is done so it is invisible to the client, then you
always end up problems with the replay protection data. If it is done
this way where the client is aware of the different cluster members
then there is no problem with the replay protection data. 

> mechanism seems to leave open.

No, this draft addresses just that problem, i.e. it WILL NOT throw
away IKE states from peer to another. It will simply clone the current
IKEv2 SA, so after the operation there are two completely independent
IKEv2 SAs. Each of those IKEv2 SAs have their own replay windows, and
counters, and both have their own independent set of Child SAs.

The draft mentions tha twe already have MOBIKE which can be used to
move the IKEv2 SA and all associated Child SAs from one IP to another,
i.e. it can be used to transfer SA from one IP address to another, and
if the second IP address is not actually in the same physical box, but
happens to be IP address of the another member in the shared cluster,
that is something that client cannot know. The cluster just then need
to make sure that it transfers the another independed IKE SA to that
other peer when doing mobike operation to change the IP address. 

> For instance, I would much rather see some informational exchange
> method or create child sa method using the existing IKE SA for
> conveying this information and somehow creatie the additional new
> Child SA.

I do not understand what you are meaning here. 

> Throwing around private keys or computed shared secrets to multiple

Private keys do not need to be transmitted, only the SKEYSEED and
material generated from there needs to be transmitted (i.e. the
computed shared state). Doing load-sharing without the client
knowledge, do require exactly same material to be transmitted, but in
addition to that all the replay protection related material needs to
be transmitted also. 
-- 
[email-masked]