Subject: [IPsec] Other documents to upgrade to internet standard

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Nov 2013 02:23:39 +0200

While we are working on the ESP, AH, IKEv2, and Architecture
documents, I think we should do also the easy ones:

- RFC2451 "The ESP CBC-Mode Cipher Algorithms"
- RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for
  Internet Key Exchange"
- RFC3948 "UDP Encapsulation of IPsec ESP Packets"

None of them has Errata, and they are all widely used, so we should
just upgrade them on in place (i.e. no need to get new RFC). 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Nov 2013 07:58:51 +0200

Hi Tero,

> - RFC2451 "The ESP CBC-Mode Cipher Algorithms"

This is nominally a generic document, but it's really about a list of 
specific algorithms, none of which is in wide use today (we are trying 
to phase out 3DES and in general 64-bit block algorithms). This document 
is not referenced by RFC 4303. So I don't think we should upgrade it.

> - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for

Yes, probably. Although crypto recommendations are time-dependent, this 
RFC describes the actual algorithms and not just their use in IKE.

Do we have enough implementations of EC groups to progress RFC 5903? I 
realize that NSA RFCs are not that popular nowadays...

> - RFC3948 "UDP Encapsulation of IPsec ESP Packets"

Definitely.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 08:24:34 +0000

On Nov 5, 2013, at 9:58 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Do we have enough implementations of EC groups to progress RFC 5903? I realize that NSA RFCs are not that popular nowadays…

How many is "enough"? I have one.

Besides, the NSA is very popular nowadays. In fact, where dedicating both tomorrow's plenary *and* the perpass session to celebrate our appreciation of the NSA.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Nov 2013 20:41:19 +0200

> is not referenced by RFC 4303. So I don't think we should upgrade it.

True, but it is one of the normative references to the RFC5996, but I
agree that if we downgrade 3DES from MUST to MAY, then we skip this
one. 

> RFC describes the actual algorithms and not just their use in IKE.

Yep. Meaning there is lots of use for these groups. 

> realize that NSA RFCs are not that popular nowadays...

No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same
IANA values for two different non-interoperable uses of the groups, I
cannot say there is enough interoperable use for that RFC.

I have recommended everybody not to use them, as you never know if
they work, as you do not know if the other end is upgraded to Errata
version of 4753 (i.e. RFC5903).

Thats why I would not recommend RFC5903 to be upgraded at this time.
And there is errata for RFC5903, so it does not go in my category of
"Easy, no need to revise document", which was my original list
selection criteria. Hmm.. actually I see that both errata entries for
the RFC5903 are actually rejected, so perhaps it could still be done
inplace. 

-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 07 Nov 2013 09:11:31 +0200

> the RFC5903 are actually rejected, so perhaps it could still be done

IIRC we published RFC 5903 using the old code points because there was 
no objection, i.e. no indication that people had deployed pre-errata 
4753. Whether this was the right thing to do or not is not very 
interesting now.

So, seeing that people are slowly moving to ECC, I would like some input 
from the group on whether to progress RFC 5903. We will need to 
demonstrate implementation experience to do that.

Thanks,
	Yaron

---

From: <[email-masked]>
Date: Thu, 7 Nov 2013 14:46:52 +0000

On Nov 7, 2013, at 2:11 AM, Yaron Sheffer <[email-masked]> wrote:

> ...
> IIRC we published RFC 5903 using the old code points because there was no objection, i.e. no indication that people had deployed pre-errata 4753. Whether this was the right thing to do or not is not very interesting now.
> 
> So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that.

"Slowly moving"?  I'm not sure they are moving at all.  It may be there are implementations of IPSec/IKE with ECC, but I've never encountered one in the wild.

	paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 15:29:24 +0000

> "Slowly moving"?  I'm not sure they are moving at all.  It may be there are implementations of IPSec/IKE with ECC, but I've never encountered one in the wild.

Huh?

The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Nov 2013 10:46:52 -0500 (EST)

> The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well.

openswan / libreswan do not support ecc at this moment.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 16:03:02 +0000

> openswan / libreswan do not support ecc at this moment.

That's the trouble with open source. You never know which fork.
https://rhn.redhat.com/errata/RHEA-2010-0411.html

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Nov 2013 11:32:58 -0500 (EST)

> https://rhn.redhat.com/errata/RHEA-2010-0411.html

Only the modp groups from RFC 5114 were added, not the ecp groups.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 17:09:42 +0000

> Only the modp groups from RFC 5114 were added, not the ecp groups.

I stand corrected.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Nov 2013 19:25:33 +0200

> 4753. Whether this was the right thing to do or not is not very 

There was very strong objection, at least from me.

http://www.ietf.org/mail-archive/web/ipsec/current/msg05445.html

And as I pointed out at that time was that our code for example was
changed to use pre errata 4753 because other implementor complained
that we did things wrong, so our toolkits are using either pre-errata
or post-errata 4753 depending on the version (very old ones use
post-errata, then several years for per-errata, and then again
post-errata). This was discussed in the email.

As an IANA expert I said we are going to allocate new numbers for
this, but area directors were against this and they managed to talk me
out it (unfortunately, I still think it would have been much better to
allocate new numbers). The only comment why keep original numbers was
that there was ONE implementation out there that used them, and that
implementation would never get updated to include new numbers if we
allocated them. I myself considered this as very weak reason, but
other people had different opinions. BTW most of this discussion
happened face-to-face, not in the mailing list.

I did point out at that time, that this will mean that those ECP
groups cannot get wide use as people cannot enable them unless they
are using exactly same version of IPsec in all of their devices, and I
have been recommending to our customers to stay away from thse groups.

> demonstrate implementation experience to do that.

I am against for RFC5903 going forward as we KNOW there is known
implemnetation issues with the groups defined there, and those
problems manifest by just causing timeouts during the IKE_AUTH
exchange, i.e. there is no proper way to do good fallback.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Nov 2013 19:43:36 +0200

Yoav Nir writes:
> The VPN products from Cisco, Juniper and Check Point support them,
> as well as both StrongSwan and OpenSwan. I'm sure there are others
> as well. 

But which version of their products support which version of the ECC
groups? For example I have no idea which version our toolkit, our
customers are using in their products, so I cannot know which version
of groups they support. I do know that some of them do use very old
versions, because there release cycle is very long.

So have you actually seen anyone actually using those groups between
different vendors? I think quite a lot of our customers still have
IKEv1 configured by default, and they have not yet moved to IKEv2
unless they want to use EAP or MOBIKE or something like that which is
only supported by IKEv2.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Nov 2013 12:52:59 -0500 (EST)

On Thu, 7 Nov 2013, Tero Kivinen wrote:

> groups?

> IKEv1 configured by default

Yes, with 3des-md5 and pfs disabled. Every single time I talk to a
sysadmin configuring interop to a Cisco. I don't think it is the
vendor's fault. It's that IPsec is too complicated for sysadmins,
so the documentation from 15 years ago is still re-used today.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 17:52:36 +0000

> versions, because there release cycle is very long.

I'm pretty sure that is true for my company's customers as well.

> different vendors?

Perhaps we should have an interop event. How about the Sunday of the London meeting?

> I think quite a lot of our customers still have

I know our default is IKEv1 and I don't think many of our customers switched to IKEv2. Perhaps now they will, because we only support IPv6 with IKEv2.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Nov 2013 08:30:36 -0800

<hat on="no">

> cannot say there is enough interoperable use for that RFC.

Nor can you say that there is *not* enough interoperable use. As others have pointed out, there are lots implementations, and as far as I have heard, all current implementations are using RFC 5930.

> version of 4753 (i.e. RFC5903).

That's fine if you want to recommend it; many implementors are ignoring you and interoperating just fine.

> happened face-to-face, not in the mailing list.

That may all be true, but it is also irrelevant to whether the RFC itself should advance. The IANA values are not in question: only the bits on the wire are covered in the RFCs. The bits on the wire in RFC 5930 are highly interoperable, as shown by many different implementations (possibly even yours).

<hat on="yes">

Do others in the WG feel that the issues Tero brought up are significant enough to prevent RFC 5930 from advancing on the standards track?

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 10 Nov 2013 20:12:32 +0200

Paul Hoffman writes:
> Nor can you say that there is *not* enough interoperable use. As
> others have pointed out, there are lots implementations, and as far
> as I have heard, all current implementations are using RFC 5930.

I agree there is enough interoperable implementations, I do not know
if they are "widely used". As far as I know people are still using
MODP DH groups when they are actually using IKEv2 in the field. 

> That's fine if you want to recommend it; many implementors are
> ignoring you and interoperating just fine. 

Again I did not recommend implementors not to implement it or fix
their code to use RFC5930 way of doing thigs, I was recommending users
not to use them unless they are sure all their environment is updated
to latest versions (which usually is not the case).

You are confusing the "use" vs "implementation" here. There needs to
be "widespread deployment and successful operational experience.", and
that at least for me would mean that actually would need to use that
feature, not just that it might be complied in to the implementation.

> That may all be true, but it is also irrelevant to whether the RFC
> itself should advance. The IANA values are not in question: only the
> bits on the wire are covered in the RFCs. The bits on the wire in
> RFC 5930 are highly interoperable, as shown by many different
> implementations (possibly even yours). 

And how does that point there is "successful operational experience"
for those groups?

When I went through the list of IPsec related standards I used
following criteria for it:

1) It is widely implemented
2) It is widely used
3) If document does not have errata, it is easy to upgrade.

The RFC6410 lists following ones:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

The first one covers my case 1 and 2. My case for 3 is more strict, as
(2) only requires there is no errata that would cause implementation
to fail. The errata in RFC4753 was definately such, the errata to
RFC5903 is not. (3) and (4) should not be problem for it.

This for example one reason I do not think we can put some of the
other ones forward either. I.e. following ones are standard track, but
even if some of them do have enough implementations, I do not think
they are used widely enough yet:

MOBIKE (4555), ECDSA (4754=>5903), OCSP extensions (4806), AEAD for
IKEv2 (5282), redirect (5685), session resumption (5723), EAP only
athentication (5998), Quick Crash Detection (6290), High Availibility
(6311).

> <hat on="yes">
> 
> Do others in the WG feel that the issues Tero brought up are
> significant enough to prevent RFC 5930 from advancing on the
> standards track? 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Nov 2013 11:58:26 -0800

> MODP DH groups when they are actually using IKEv2 in the field. 

Given that you told your customers not to the ECDSA curves, it seems sensible that you would not hear them saying that they were disagreeing with you. :-)

> You are confusing the "use" vs "implementation" here.

No, I'm not.

> There needs to

Correct. And some US government installations are seeing both, most likely because they are requiring it.

> And how does that point there is "successful operational experience"

I didn't say that it did; so, see above. There has been both conformance and interoperability testing for those curves, and day-to-day deployment. (Which is more than you can probably show for some of the two largest MODP groups in RFC 3526, but I think it is fine to leave them in because there was limited interop testing for them a decade ago and that's good enough.)

--Paul Hoffman

---

From: Andreas Steffen <[email-masked]>
Date: Tue, 12 Nov 2013 11:58:22 +0100

Hi,

speaking for the strongSwan Project I report that we
support and frequently use the following algorithms:

- RFC 5903: ECP Groups for IKE and IKEv2

- RFC 4754: IKE and IKEv2 Authentication Using the Elliptic
            Curve Digital Signature Algorithm (ECDSA)

- RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec ESP

ECP, ECDSA and AES-GCM interoperability has been successfully
tested multiple times with Microsoft's Vista/Windows 7 IKEv1
Advanced Firewall implementation.

Additionally starting with strongSwan 5.1.1, we support

- RFC 6932: Brainpool Elliptic Curves for the IKE
            Group Description Registry

as an alternative for the NIST curves.

Best regards

Andreas

On 11/07/2013 04:29 PM, Yoav Nir wrote:
> 
> On Nov 7, 2013, at 6:46 AM, <[email-masked]> wrote:
> 
>> 
>>> ... IIRC we published RFC 5903 using the old code points because
>>> there was no objection, i.e. no indication that people had
>>> deployed pre-errata 4753. Whether this was the right thing to do
>>> or not is not very interesting now.
>>> 
>>> So, seeing that people are slowly moving to ECC, I would like
>>> some input from the group on whether to progress RFC 5903. We
>>> will need to demonstrate implementation experience to do that.
>> 
>> "Slowly moving"?  I'm not sure they are moving at all.  It may be
>> there are implementations of IPSec/IKE with ECC, but I've never
>> encountered one in the wild.
> 
> Huh?
> 
> The VPN products from Cisco, Juniper and Check Point support them, as
> well as both StrongSwan and OpenSwan. I'm sure there are others as
> well.
> 
> Yoav

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Nov 2013 09:59:24 -0800

> Perhaps we should have an interop event. How about the Sunday of the London meeting?

Tero was probably talking about using them in the wild, not at an interop event. We have messages saying that vendors have shown interop among themselves, so an interop event just for this point is overkill, given the amount of work it takes to organize everyone.

--Paul Hoffman