Subject: [IPsec] Proposed wording for a revised charter

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 01 Mar 2016 08:18:20 -0800

Greetings. We need to update our charter to reflect our current and 
expected work. Dave and I propose the following text. Please let us know 
within the next week if you have suggestions for changes.

--Paul Hoffman and Dave Waltermire

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated 
RFCs),
IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec 
is
widely deployed in VPN gateways, VPN remote access clients, and as a
substrate for host-to-host, host-to-network, and network-to-network
security.

The IPsec Maintenance and Extensions Working Group continues the work of
the earlier IPsec Working Group which was concluded in 2005. Its purpose 
is
to maintain the IPsec standard and to facilitate discussion of 
clarifications,
improvements, and extensions to IPsec, mostly to IKEv2.
The working group also serves as a focus point for other IETF Working 
Groups
who use IPsec in their own protocols.

The current work items include:

IKEv2 contains the cookie mechanism to protect against denial of service
attacks. However this mechanism cannot protect an IKE end-point 
(typically,
a large gateway) from "distributed denial of service", a coordinated 
attack by
a large number of "bots". The working group will analyze the problem and
propose a solution, by offering best practices and potentially by 
extending
the protocol.

IKEv2 utilizes a number of cryptographic algorithms in order to provide
security services. To support interoperability a number of mandatory-to-
implement (MTI) algorithms are defined in RFC4307. There is interest in
updating the MTIs in
RFC4307 based on new algorithms, changes to the understood security
strength of existing algorithms, and the degree of adoption of 
previously
introduced algorithms. The group will revise RFC4307 proposing updates 
to
the MIT algorithms used by IKEv2 to address these changes.

There is interest in supporting Curve25519 and Curve448 for ephemeral 
key
exchange in the IKEv2 protocol. The group will extend the
IKEv2 protocol to support key agreement using these curves and their
related functions.

This charter will expire in August 2016. If the charter is not updated 
before
that time, the WG will be closed and any remaining documents revert back 
to
individual Internet-Drafts.

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 1 Mar 2016 09:07:46 -0800 (PST)

Shall we include firewall traversal/TCP encapsulation as part of the charter as discussed in draft-pauly-ipsecme-tcp-encaps?

Cheers,
-Victor

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: 01 March 2016 17:18
To: IPsecME WG <[email-masked]>
Subject: [IPsec] Proposed wording for a revised charter

Greetings. We need to update our charter to reflect our current and expected work. Dave and I propose the following text. Please let us know within the next week if you have suggestions for changes.

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),
IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2.
The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols.

IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol.

IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to- implement (MTI) algorithms are defined in RFC4307. There is interest in updating the MTIs in
RFC4307 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 proposing updates to the MIT algorithms used by IKEv2 to address these changes.

There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange in the IKEv2 protocol. The group will extend the
IKEv2 protocol to support key agreement using these curves and their related functions.

This charter will expire in August 2016. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Mar 2016 15:32:17 -0500

S/mostly// 

Add IKE over tcp and DNS extensions for ikev2?

Sent from my iPhone

> On Mar 1, 2016, at 11:18, Paul Hoffman <[email-masked]> wrote:
> 
> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is
> the earlier IPsec Working Group which was concluded in 2005. Its purpose is
> to maintain the IPsec standard and to facilitate discussion of clarifications,
> attacks. However this mechanism cannot protect an IKE end-point (typically,
> a large gateway) from "distributed denial of service", a coordinated attack by
> propose a solution, by offering best practices and potentially by extending
> the protocol.
> 
> strength of existing algorithms, and the degree of adoption of previously
> introduced algorithms. The group will revise RFC4307 proposing updates to
> There is interest in supporting Curve25519 and Curve448 for ephemeral key
> This charter will expire in August 2016. If the charter is not updated before
> that time, the WG will be closed and any remaining documents revert back to

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Mar 2016 13:02:57 +0200

> within the next week if you have suggestions for changes.

Should we add something about making the IKEv2 resistant to QC based
attacks?

Btw, looking at the latest attacks against TLS using SSLv2, the IKEv1
parts of the IPsec implementations are starting to scare me. I mean
there is lots of old code there, that is not really updated anymore as
the IKEv1 is obsoleted, and that code can be used to attack IPsec
implementations. We have some customers asking about the DoS attacks
IKEv1 using IKEv1 server as packet reflektor, then there is the sloth
attack which worked much better against IKEv1 because it used MD5 etc.

The problem is that lots of people are still using IKEv1, and there is
not really good push away from it. I think it would be good idea to
give bit more push to that, i.e., perhaps having
draft-ietf-ipsecme-ikev1-diediediediedie (sslv2 and des only needed 3
dies, but IKEv1 is such zombie, that I do not think that killing it 3
times is enough :-) explaining why implementations should not use
IKEv1.

This is of course will not really change anything, but at least I
could use it here in to convince customers that they need to move away
from IKEv1, and perhaps it would wake up some implementors who only
have IKEv1 in their implementations. Perhaps it could even provide
some kind of transition plan: Stop using IKEv1 as default by now,
disable automatic fallback by 2017 and require manual configuration to
use it, and remove the support of IKEv1 completely from implemenations
by 2020. 
-- 
[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 04 Mar 2016 09:05:43 -0800

I would also like to see the draft for TCP encapsulation added as an item, since we’ve gotten a fair amount of support for it. For the purposes of the charter, it may be good to have a broader explanation of the goal—something to the effect that the working group should focus on making sure that IKEv2 can be deployed more universally by taking into account limitations of various networks. Previous RFCs like IKE fragmentation have contributed to this; TCP encapsulation tries to solve another set of problematic networks; and we can imagine that there may be more to investigate, such as taking into account the limitations and requirements of IoT networks, etc.

Tommy

> On Mar 1, 2016, at 12:32 PM, Paul Wouters <[email-masked]> wrote:
> 
> S/mostly// 
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 4 Mar 2016 19:35:31 +0200

+1 

Speaking as an implementer, we have done something similar for our IKEv1 clients, and would be happy to have something standards-based for IKEv2.

I would be happy to see this work become an RFC.

Yoav

> On 4 Mar 2016, at 7:05 PM, Tommy Pauly <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Mar 2016 15:47:06 -0500 (EST)

> I would also like to see the draft for TCP encapsulation added as an item, since we’ve gotten a fair amount of support for it. For the purposes of the charter, it may be good to have a broader expl…

Yes please. Note there is also the DNS(SEC) work in our other draft as
well.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Mar 2016 15:23:52 +0000

On Fri, Mar 4, 2016 at 5:05 PM, Tommy Pauly <[email-masked]> wrote:

> I would also like to see the draft for TCP encapsulation added as an item,
> since we’ve gotten a fair amount of support for it.

I am supporting this item.

> For the purposes of the charter, it may be good to have a broader
> explanation of the goal—something to the effect that the working group
> should focus on making sure that IKEv2 can be deployed more universally by
> taking into account limitations of various networks. Previous RFCs like IKE
> fragmentation have contributed to this; TCP encapsulation tries to solve
> another set of problematic networks; and we can imagine that there may be
> more to investigate, such as taking into account the limitations and
> requirements of IoT networks, etc.
>
> Tommy
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Mar 2016 15:59:26 +0000

Hi,

We would like to add the definition of YANG models for IKEv2 and IPsec as
items of the charter. The intent of such models is to be able to provide
configurations that are implementations independent. Of course IPsecme will
be expected to provide feed backs/comments on the data model which does not
require any YANG knowledge. YANG aspects will be validated by YANG
tools/community.

We will publish a draft that proposes a YANG model for IKEv2 by next week.
Future drafts on for IPsec will be provided later too.
BR,

Daniel

---

From: Daniel Palomares <[email-masked]>
Date: Mon, 14 Mar 2016 10:49:45 +0100

Hello,

I would like to propose MOBIKEv2 as part of the charter.

What it basically proposes is to add MOBIKE support for Transport Mode (and
not only tunnel mode). The most suitable scenarios that would benefit from
this are any-to-any networks implementing IPsec in transport mode.

MOBIKEv2 has already been presented at the ietf>ipsecme meetings.

BR,

Daniel Palomares

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Mar 2016 06:45:49 -0400 (EDT)

On Mon, 14 Mar 2016, Daniel Palomares wrote:

> What it basically proposes is to add MOBIKE support for Transport Mode (and not only tunnel mode). The most suitable scenarios that would
> benefit from this are any-to-any networks implementing IPsec in transport mode.

I dont even understand how that would work in transport mode, but I'm
not a MOBIKE expert.

Probably best to discuss this in the working group, then when the
workgring group sees this as something to work on, we could add it to
the charter?

Paul

---

From: Daniel Palomares <[email-masked]>
Date: Mon, 21 Mar 2016 16:54:34 +0100

Hello Paul,

MOBIKEv2 was already presented in IETF90.
https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-3.pdf
We had little discussion, but I felt there was interest on this proposal.

Actually what MOBIKEv2 proposes, is to change the IP used in the IKE
Security Association without having to renegotiate the whole set of keys
again. As transport mode addresses endpoint-to-endpoint communications, the
most suitable scenarios are any-to-any networks willing to communicate
using IPsec.
https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-2.pdf

Regards
Daniel

2016-03-14 11:45 GMT+01:00 Paul Wouters <[email-masked]>:

>> What it basically proposes is to add MOBIKE support for Transport Mode
>> (and not only tunnel mode). The most suitable scenarios that would

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 21 Mar 2016 10:58:08 -0700

> We had little discussion, but I felt there was interest on this 

I understand that it was discussed in the distant past, and that there 
was a tad of interest. That's not enough to get it in the charter.

--Paul Hoffman