Subject: [IPsec] Agenda for IETF 100

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Oct 2017 22:23:14 +0300

We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our
main agenda item will be the rechartering text, i.e., our charter will
expire by the end of year, and we have most of our chartered work
already completed, or almost finished, so we need to decide what new
items (if any) we take to our charter, or wheter we shut down the WG.

In last IETF we had people with items which we could add to charter,
so I want those people wanting to add things to charter to send an
email to the mailing list about what items they would like to propose
to the charter, and preliminary charter text for the item.

If we do not receive any proposed charter texts, then I assume we do
not have any more work to do after we finish our current charter...

Also if there is people wanting to present anything in the next
IPsecME IETF session, send email to wg chairs [email-masked]. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Oct 2017 23:58:29 +0300

There used to be a special working group for multicast security. That has closed, so IPsecME is the natural home for this work:

The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based 
protocol for negotiating group keys for both multicast and unicast uses. The 
Working Group will develop an IKEv2-based alternative that will include 
cryptographic updates. A possible starting point is draft-yeung-g-ikev2

Brian, Valery, and Yoav

> On 26 Oct 2017, at 22:23, Tero Kivinen <[email-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 27 Oct 2017 17:51:34 +0300

Hi,

I think that the following items can be considered for the new charter.

1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter text:

	MOBIKE protocol [RFC4555] is used to move existing
	IKE/IPsec SA from one IP address to another. However,
	in MOBIKE it is the initiator of the IKE SA (i.e. remote access client)
	that controls this process. If there are several responders 
	each having own IP address and acting together as a load sharing cluster,
	then it is desirable for them to have ability to request initiator to switch to 
	a particular	member. The working group will analyze the possibility
	to extend MOBIKE protocol or to develop new IKE extension
	that will allow to build load sharing clusters in an interoperable way.

2. Make IKEv2 Postquantum Cryptography ready. In particular - make it
    able to transfer large payloads in initial exchange without having
    IP fragmentation issues. The possible charter text:

	Postquantum Cryptography brings new key exchange methods.
	Most of these methods that are known to date have much larger public
	keys then conventional Diffie-Hellman public keys. Direct using
	these methods in IKEv2 might lead to a number of problems
	due to the increased size of initial IKEv2 messages. The working group will 
	analyze the possible problems and develop a solution, that will
	make adding Postquantum key exchange methods more easy.

Regards,
Valery.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 27 Oct 2017 09:33:03 -0700

+ 1 to these proposals

I'd also like to see the work on drafts like DIET-ESP (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some growing use cases for IPsec in constrained networks, and as that develops, extensions and modifications to the protocol to make IKEv2 and ESP work efficiently in those conditions will be necessary. (These would likely fall into the host-to-host use case described in the charter.)

Thanks,
Tommy

> On Oct 27, 2017, at 7:51 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 27 Oct 2017 18:13:38 -0400

We support the proposals and will publish updated the documents regarding
diet-esp and its associated IKEv2 extension. We believe
draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a
good starting point.

The proposed text for the charter could be:
A growing number of use cases for constraint network - but not limited to -
have shown interest in reducing ESP overhead by compressing ESP fields. The
WG will define extensions of ESP and IKEv2 to enable ESP header
compression.

draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are
expected to be good starting points.

Yours,
Daniel

On Fri, Oct 27, 2017 at 12:33 PM, Tommy Pauly <[email-masked]> wrote:

> + 1 to these proposals
>
> I'd also like to see the work on drafts like DIET-ESP
> (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some
> growing use cases for IPsec in constrained networks, and as that develops,
> extensions and modifications to the protocol to make IKEv2 and ESP work
> efficiently in those conditions will be necessary. (These would likely fall
> into the host-to-host use case described in the charter.)
>
> Thanks,
> Tommy
>

---

From: [email-masked]
Date: Fri, 27 Oct 2017 19:05:03 -0400 (EDT)

Don't forget to add this as a BoF:
https://www.youtube.com/watch?v=FoUWHfh733Y

:)

X

On Fri, 27 Oct 2017, Daniel Migault wrote:

>       (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll
>       have some growing use cases for IPsec in constrained networks,
>       and as that develops, extensions and modifications to the
>       protocol to make IKEv2 and ESP work efficiently in those
>       conditions will be necessary. (These would likely fall into the
>       host-to-host use case described in the charter.)
>
>       Thanks,
>       Tommy
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Oct 2017 05:07:48 -0400 (EDT)

> to the charter, and preliminary charter text for the item.

<putting on my red hat>

In IKEv1, we have support for Labeled IPsec, which can be used to
mark traffic with labels (secret, top secret, etc) across an IPsec
connection. Libreswan implements this supporting SElinux labels using
a private allocation (after an allocation was stolen and then asisgned
to ECN :)

We have a need to have an IKEv2 version of Labeled IPsec.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 28 Oct 2017 16:13:57 +0300

Hi Daniel,
probably we need to consider Diet-IKE too? Aa companion for Diet-ESP.
And what is draft-ipsecme-ikev2-extention? I cannot find such a draft...
Regards,
Valery.
 
We support the proposals and will publish updated the documents regarding diet-esp and its associated IKEv2 extension. We believe  draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a good starting point. 

A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP overhead by compressing ESP fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression.  

draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-extention are expected to be good starting points. 

Yours, 

Daniel

  + 1 to these proposals

  Thanks,
  Tommy

---

From: Daniel Migault <[email-masked]>
Date: Sat, 28 Oct 2017 12:00:12 -0400

Hi Valery,

Absolutely, Diet-IKE would be a nice item have in the charter as well, but
this is a different item.

Currently the work on compressing esp has two items:
* draft-mglt-ipsecme-diet-esp defines how to esp.
* draft-mglt-ipsecme-ikev2-diet-esp-extension defines how peers agree on
using diet-esp

I see draft-smyslov-ipsecme-ikev2-compression [3] and
draft-smyslov-ipsecme-ikev2-compact [4] focused on the compression of ikev2
itself.

draft-ipsecme-ikev2-extention was a misspelt name for
draft-mglt-ipsecme-ikev2-diet-esp-extension [2].

If we are adding this item the text for the charter should be updated
around:

OLD:

draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
are expected to be good starting points.

NEW:
A growing number of use cases for constraint network - but not limited to -
have shown interest in reducing ESP (resp. IKEv2) overhead by compressing
ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to
enable ESP header compression.

draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension
are expected to be good starting points for ESP compression.
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2
compression.

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
[2]
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/
[3]
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compression/
[4] https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/

On Sat, Oct 28, 2017 at 9:13 AM, Valery Smyslov <[email-masked]> wrote:

> A growing number of use cases for constraint network - but not limited to
> - have shown interest in reducing ESP overhead by compressing ESP fields.
> The WG will define extensions of ESP and IKEv2 to enable ESP header
> compression.
>
>> (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have
>> some growing use cases for IPsec in constrained networks, and as that
>> develops, extensions and modifications to the protocol to make IKEv2 and
>> ESP work efficiently in those conditions will be necessary. (These would
>> likely fall into the host-to-host use case described in the charter.)
>>
>> Thanks,
>> Tommy
>>

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Sat, 28 Oct 2017 18:53:34 +0000

> From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov

[HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)) can't be used for this purpose?

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 28 Oct 2017 22:42:21 +0300

Hi Jun,

> that will allow to build load sharing clusters in an interoperable way.

[HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)) can't be used for this 
purpose?

The problem with IKE Redirect is that it requires IKE SA to be re-established from scratch.
It consumes quite a lot of resources and takes noticeable amount of time. Moreover,
in some cases it could require human interaction (in case of some EAP methods or
if access to client's credentials requires entering PIN), so it may be inappropriate.
The idea is to have a solution that utilizes already established IKE SA and moves
it (along with its Child SAs) from one cluster member to another without creating
new IKE SA.

Regards,
Valery.

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Sat, 28 Oct 2017 19:57:03 +0000

> -----Original Message-----
> From: Valery Smyslov [mailto:[email-masked]]
> > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible
> > charter
> > text:
> >
> > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from
> > one IP address to another. However, in MOBIKE it is the initiator of
> > the IKE SA (i.e. remote access client) that controls this process. If
> > there are several responders each having own IP address and acting
> > together as a load sharing cluster, then it is desirable for them to
> > have ability to request initiator to switch to a particular member.
> > The working group will analyze the possibility to extend MOBIKE
> > protocol or to develop new IKE extension that will allow to build load
> > sharing clusters in an interoperable way.
> 
> [HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange
> Protocol Version 2 (IKEv2)) can't be used for this purpose?
> 
> It consumes quite a lot of resources and takes noticeable amount of time.
> Moreover, in some cases it could require human interaction (in case of some
> EAP methods or if access to client's credentials requires entering PIN), so it
> may be inappropriate.
> The idea is to have a solution that utilizes already established IKE SA and
> moves it (along with its Child SAs) from one cluster member to another
> without creating new IKE SA.

[HJ] two questions:
1. this sound interesting, however how to do it securely is the most important question, do you already have draft?

2. if the use case is load-balance, then  wouldn't it be better off to make a selection right upon client connects (e.g. redirect during IKE_AUTH) than move SA around after tunnel is established  ?

---

From: Paul Wouters <[email-masked]>
Date: Sun, 29 Oct 2017 01:27:51 -0400 (EDT)

> 2. if the use case is load-balance, then  wouldn't it be better off to make a selection right upon client connects (e.g. redirect during IKE_AUTH) than move SA around after tunnel is established  ?

I think a document describing how best to load load balancing AND
failover support for IPsec would be useful, irrespective of the
existing RFC's or existing/future drafts which we would use. For
example, a document listing:

- Client behaviour to Access VPN failover
- Net-to-Net failover over different uplinks
- Hardware pair failover with state within a datacenter
- Crypto Mesh migration
- Maybe some IPsec/NHRP advise?

Another thing we might want to reconsider is something to talk
about mesh encryption / auto-vpn in general. While earlier work
to come up with a single solution failed, there is still a market
need, and I'm a little fearful of SDN removing IKE from the setup.

Paul
Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 29 Oct 2017 09:55:42 +0300

Hi,

> 1. this sound interesting, however how to do it securely is the most important question, do you already have draft?

draft-smyslov-ipsecme-ikev2-r-mobike

> 2. if the use case is load-balance, then  wouldn't it be better off to make a selection right upon client connects 
> (e.g. redirect during IKE_AUTH) than move SA around after tunnel is established  ? 

This is definitely an option (ant even can be achieved with IKE redirect).
However, once client is connected you cannot move it to another member,
so depending on clients' activity members load can become very uneven and
you cannot balance it without forcing clients to reconnet. The desire is to 
be able to dynamically balance members load.

Regards,
Valery.

---

From: Daniel Migault <[email-masked]>
Date: Sun, 29 Oct 2017 21:38:18 -0400

Hi,

A few years ago, we worked on fail-over, load balancing.. [1] and would be
happy to help.

Yours,
Daniel

[1]
https://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01

On Sun, Oct 29, 2017 at 2:55 AM, Valery Smyslov <[email-masked]> wrote:

> Hi,
>
> The problem with IKE Redirect is that it requires IKE SA to be
>>> re-established
>>> from scratch.
>> 1. this sound interesting, however how to do it securely is the most
>> important question, do you already have draft?
>>
>
> 2. if the use case is load-balance, then  wouldn't it be better off to
>> make a selection right upon client connects (e.g. redirect during IKE_AUTH)
>> than move SA around after tunnel is established  ?
>>
>
> you cannot balance it without forcing clients to reconnet. The desire is
> to be able to dynamically balance members load.
>
> Regards,
> Valery.
>
>

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 30 Oct 2017 03:46:56 +0000

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Saturday, October 28, 2017 10:28 PM
> To: Hu, Jun (Nokia - US/Mountain View) <[email-masked]>
> Cc: Valery Smyslov <[email-masked]>; 'Tero Kivinen' <[email-masked]>;
> [email-masked]
> Subject: Re: [IPsec] Agenda for IETF 100
> 
> >> re-established from scratch.
> >> Moreover, in some cases it could require human interaction (in case
> >> of some EAP methods or if access to client's credentials requires
> >> entering PIN), so it may be inappropriate.
> >> The idea is to have a solution that utilizes already established IKE
> >> SA and moves it (along with its Child SAs) from one cluster member to
> >> another without creating new IKE SA.
> >
> > [HJ] two questions:
> > 2. if the use case is load-balance, then  wouldn't it be better off to make a
> selection right upon client connects (e.g. redirect during IKE_AUTH) than move
> SA around after tunnel is established  ?
> 
> I think a document describing how best to load load balancing AND failover
> support for IPsec would be useful, irrespective of the existing RFC's or
> existing/future drafts which we would use. For example, a document listing:
> 

[HJ]  I think it would be good to have use case/requirement defined first, because different use cases has different requirements, which might leads to different solution; e.g. remote-access client (e.g. road warrior) connect to one cluster of GWs (ad hoc)  is different from a branch router connects to HQ (always on); where latter could just use routing/ecmp to achieve load balancing, doesn't need anything new;

> Another thing we might want to reconsider is something to talk about mesh
> encryption / auto-vpn in general. While earlier work to come up with a single
> solution failed, there is still a market need, and I'm a little fearful of SDN
> removing IKE from the setup.

[HJ] there is clear market requirement for an auto-discover encryption VPN, however again depends on the use case, the solution might not need to extend IPsec; for example, for router interconnection , I could see extending BGP (e.g. tunnel encaps attr) to carry gw address or other ipsec profiles info along with routes be a solution