Subject: [Softwires] security requirement: IKEv1 vs. IKEv2?

From: Florent Parent <[email-masked]>
Date: Tue, 05 Dec 2006 09:42:54 -0500

We are currently updating the security requirement draft, and need some 
feedback from the group concerning the IPsec protocol suite, or more 
precisely whether IKEv2 should be a 'MUST' in softwire phase 0.

Background information:

1- From the softwire problem statement draft: "The goal of this effort is 
to reuse or extending existing technology.  The 'time-to-market' 
requirement for solutions to the stated problems is very strict and 
existing, deployed technology must be very strongly considered in our 
solution selection."

2- IKEv2 obsoletes IKEv1. New protocols should use IKEv2.

3- NAT-traversal is a 'MUST' in softwire, so NAT-traversal for  IKE and ESP 
are required (RFC3947/3948, and part of IKEv2)

Hub and spokes phase 0 is to use L2TPv2. Deployed clients that support 
L2TPv2 today likely support IKEv1 for securing L2TPv2 (RFC3193, Securing 
L2TP using IPsec). NAT-traversal for IKE and ESP is also deployed today in 
recent OS.

Question are (for Hub and Spokes case):

- Do we focus on IKEv1 + IPsec NAT-traversal (RFC3947/3948) for the "H&S" 
and IKEv2 for the "Mesh" scenario? This would basically be referring to 
RFC3193 + RFC3947/3948

- Recommend IKEv2 everywhere?

- Dual approach: IKEv1 for phase 0, IKEv2 in phase 1?

Note that IKEv2 makes sense in the context of the "Mesh" scenario since 
that scenario does not have existing deployments today.

Comments/guidance welcomed.

Florent

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Dec 2006 17:01:11 +0200

> - Do we focus on IKEv1 + IPsec NAT-traversal (RFC3947/3948) for the "H&S" 

I assume "H&S" then do not use any new features of IKEv2 like EAP
authentication, assigning addressed using configuration payloads,
faster creation of initial SAs (4 packets versus 9 packets),
protection against denial of service attacks, reliable rekeying of IKE
and IPsec SAs, more complex traffic selector negotiations (i.e.
list of address ranges instead of single address or single ranges), or
does not require any RFC4301 or RFC4306 based new features like
combined cipher algorithms or TFC etc...

IKEv2 is much better and much more reliable protocol than IKEv1...

> - Recommend IKEv2 everywhere?

I would suggest this option, unless you are certain that you can
configure already existing and deployed boxes to support everything in
H&S without ANY changes to the software in those boxes.
-- 
[email-masked]

---

From: Florent Parent <[email-masked]>
Date: Tue, 05 Dec 2006 11:04:42 -0500

> authentication,  assigning addressed using configuration payloads,

Address configuration is done using router advertisements for IPv6, or PPP 
IPCP for IPv4 (PPP is used in phase 0)

> faster creation of initial SAs (4 packets versus 9 packets),

Would certainly be more efficient. But putting this in context of the 
session "bootstrap" where we have L2TPv2 control setup, session setup, PPP 
LCP+auth, RS/RA, and DHCPv6-PD, we are around 20 packets already.  But 
during re-keying, I guess there is an important gain.

> IKEv2 is much better and much more reliable protocol than IKEv1...

Agreed.

> H&S without ANY changes to the software in those boxes.

This pretty much sums this up. Maybe someone from the "hub and spokes" 
design document can comment on this?

Thanks
Florent

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 05 Dec 2006 14:28:33 -0200

I agree and will much prefer to use always IKEv2.

Regards,
Jordi

> De: Tero Kivinen <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 5 Dec 2006 17:01:11 +0200
> Para: Florent Parent <[email-masked]>
> CC: <[email-masked]>
> Asunto: [Softwires] security requirement: IKEv1 vs. IKEv2?
> 
> Florent Parent writes:

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 5 Dec 2006 08:41:38 -0800

One thing to keep in mind as well is that IKEv1 and IKEv2 are not  
backwards compatible so if you don't recommend IKEv2 everywhere you  
may end up with interoperability problems down the line.

Since IKEv2 is known to be a more reliable and better protocol I  
would vote for the option to recommend IKEv2 everywhere.

- merike

On Dec 5, 2006, at 8:04 AM, Florent Parent wrote:

>
>
> --On 5 décembre 2006 17:01:11 +0200 Tero Kivinen  
> <[email-masked]> wrote:
>
>> Florent Parent writes:
> Address configuration is done using router advertisements for IPv6,  
> or PPP IPCP for IPv4 (PPP is used in phase 0)
>
> Would certainly be more efficient. But putting this in context of  
> the session "bootstrap" where we have L2TPv2 control setup, session  
> setup, PPP LCP+auth, RS/RA, and DHCPv6-PD, we are around 20 packets  
> already.  But during re-keying, I guess there is an important gain.
>
> This pretty much sums this up. Maybe someone from the "hub and  
> spokes" design document can comment on this?
>
> Thanks
> Florent
>
>
>
>
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Dec 2006 22:53:13 +0100

In your previous mail you wrote:

   

=> recommend (2) because the only good reason to use IKEv1 is to have
only an IKEv1 implementation, so it should be only a temporary situation
which can end before the document is published or applied...
To summary, this what means "obsolete by".

Regards

[email-masked]

---

From: Florent Parent <[email-masked]>
Date: Wed, 06 Dec 2006 22:16:35 -0500

Thanks to all for the feedback. The draft update will recommend IKEv2 in 
all cases.

Florent

--On 6 décembre 2006 22:53:13 +0100 Francis Dupont 
<[email-masked]> wrote:

>    - Do we focus on IKEv1 + IPsec NAT-traversal (RFC3947/3948) for the
> "H&S"     and IKEv2 for the "Mesh" scenario? This would basically be
> referring to     RFC3193 + RFC3947/3948
>