Subject: Node Requirements: Issue 17 - IPsec/IKE

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Jul 2010 17:27:09 -0400

Folks,

A revised version of draft-ietf-6man-node-req-bis-05.txt has been
published, but it's Security section needs work. In particular, the WG
needs to answer the following questions:

 - Should IPsec be a SHOULD or MUST?
 - What about IKEv2?

Let me start with some background:

RFC 4294 says the following:

> 8.  Security
> 
>    This section describes the specification of IPsec for the IPv6 node.
> 
> 8.1.  Basic Architecture
> 
>    Security Architecture for the Internet Protocol [RFC-4301] MUST be
>    supported.
>
> 8.2.  Security Protocols
> 
>    ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.

...

> 8.4.  Key Management Methods

>    An implementation MUST support the manual configuration of the
>    security key and SPI.  The SPI configuration is needed in order to
>    delineate between multiple keys.
> 
>    Key management SHOULD be supported.  Examples of key management
>    systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include
>    key management functions.
> 
>    Where key refresh, anti-replay features of AH and ESP, or on-demand
>    creation of Security Associations (SAs) is required, automated keying
>    MUST be supported.
> 
>    Key management methods for multicast traffic are also being worked on
>    by the MSEC WG.

There are a couple of problems with the above text.

First, AH [RFC4302] is listed as a MUST. This is old/obsolete. The
newer versions of the IPsec architecture have changed this to a
MAY. ESP now includes integrity protection, so one can achieve
authentication via ESP and NULL encryption. Thus, the node
requirements document will change AH to a MAY. (This should not be a
controversial change.)

The real issue though is as follows:

The key managment recommendation is only a SHOULD, yet doesn't
actually recommend one particular protocol. That said, the only
available key management protocol is effectively IKE. Thus, the Node
Requirements recommendation is a SHOULD for IKE (and IKEv2 in
particular).

But, RFC 4301 (the Security Architecture) is listed as a MUST. If one
looks at 4301 closely, it effectively mandates IKEv2 (see
http://www.ietf.org/mail-archive/web/ipsec/current/msg06259.html). That
is, the IPv6 Node Requirements RFC says SHOULD for IKEv2, yet
indirectly also says MUST for IKEv2. Talk about wanting it both
ways...

Some more thoughts.

1) Mandating IPsec (just ESP) without also supporting a key management
   protocol has rather limited applicability. For many years, the IPv6
   WG has insisted on IPsec being a MUST (for strong security), but in
   the absence of key management, that requirement (IMO) rings hollow.

2) The IPv6 WG has in the past been hesitant to mandate IKE for all
   hosts. This was viewed as a difficult requirement for some
   devices. Although there are more implementations of IKE today, I
   suspect there would still be hesitation to mandate IKE on all
   nodes.

3) We've gained a lot of experience with security and security
   protocols over the last decade.  If there is one overarching
   lesson, it's that security isn't easy, and it's not just about
   protocols. It's also about key distribution, certificates,
   operational practices, etc.

   Moreover, it is now recognized that with security, there is no
   one-size-fits-all panacea. We have a plethora of security
   technologies (ssh, ssl, tls, IPsec, etc.) and some really are more
   appropriate for some applications than others.  So IPsec is not
   going to turn out to be the single "holy grail" security
   technology. It has its place, and I expect we'll see a lot more
   usage of it over the next decade, but it is not likely to displace
   all other approaches. And for some classes of devices and
   applications, other security protocols will be more appropriate
   than IPsec.

4) The breadth and range of devices that support IP is simply
   staggering. Many are small, and some are so small, they really do
   have legitmate issues with supporting IKEv2. Does it make sense for
   the IETF to mandate that an iPod run IPsec and/or IKE? Sensor
   devices?  Personally, I don't think so.

   Even the current recommendation that IPsec/ESP be a MUST seems a
   bit like ivory-tower syndrome. IPsec does make sense in a lot of
   environments, but simply isn't required in all devices. And having
   the IETF say it is required hasn't forced all vendors to implement
   IPsec in their devices.

Thus, it is my recommendation that the next version of the node
requirements document make support for IPsec and IKE both SHOULDs
only, with a lot more explanatory text that makes it clear that there
are some types of devices where IPsec is not necessarily the best
choice.

Thoughts?

Proposed new text:

10.  Security

   This section describes the specification of IPsec for IPv6 nodes.

   Achieving security in practice is a complex undertaking.
   Operational procedures, protocols, key distribution mechanisms,
   certificate management approaches, etc. are all components that
   impact whether security is actually achieved in practice. More
   importantly, deficiencies or a poor fit in any one individual
   component can significantly reduce the overall effectiveness of an
   particular security approach.

   IPsec provides channel security at the Internet layer, making it
   possible to provide secure communication for communication flows
   between pairs of internet hosts. IPsec provides sufficient
   flexibility and granularity that individual TCP connections can
   (selectively) be protected, etc.

   IKEv2 is the key management protocol for IPsec. Although manual
   keying can be used with IPsec in some cases, the overall
   applicability of statically configured keys is limited. Thus, IPsec
   without IKEv2 has only limited value.

   A range of security technologies and approaches proliferate today
   (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has
   emerged as an ideal technology for all needs. It seems clear that
   for the foresable future, that situation will not change. Moreover,
   IPsec is not viewed as the ideal security technology for all
   approaches and is unlikely to displace the others. That is, IPsec
   is not viewed as a good choice for all security needs.

   Previously, IPv6 mandated implementation of IPsec and recommended
   the key management approach of IKE. This document updates that
   recommendation by making support of both IPsec and IKEv2 a SHOULD
   for IPv6 nodes. In particular, it is recognized that there are a
   range of device types and environments where other approaches to
   security than IPsec can be more appropriate. This is particularly
   the case for smaller specialized, single-purpose devices that
   support only very limited applications or run on constrained
   hardware. In other environments, support for IPsec and IKEv2 should
   be considered a very strong SHOULD, if not a MUST.

10.1.  Requirements

   Security Architecture for the Internet Protocol [RFC4301] SHOULD be
   supported by all nodes. Those nodes implementing the Security
   Archecture MUST support ESP [RFC4303] and MAY support AH
   [RFC4302]. In addition, such nodes SHOULD implement IKEv2 [RFC4306].

10.2.  Transforms and Algorithms

   The current set of mandatory-to-implement algorithms for ESP and AH
   are defined in 'Cryptographic Algorithm Implementation Requirements
   For ESP and AH' [RFC4835].  IPv6 nodes implementing IPsec MUST
   conform to the requirements in [RFC4835].

10.3.  Key Management Methods

   An implementation MUST support the manual configuration of the
   security key and SPI.  The SPI configuration is needed in order to
   delineate between multiple keys.

   Where key refresh, anti-replay features of AH and ESP, or on-demand
   creation of Security Associations (SAs) is required, IKEv2 keying
   MUST be supported.

---

From: <[email-masked]>
Date: Tue, 20 Jul 2010 23:44:34 +0200

Hi Thomas,

I agree with your analysis and recommendation.
I support the idea of specifying IPSec/IKEv2 as a SHOULD in the node
requirements I-D.

-Raj

On 7/20/10 4:27 PM, "Thomas Narten" <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 20 Jul 2010 17:16:43 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 

> are some types of devices where IPsec is not necessarily the best

YES!

I think this has become a big obstacle to deploying IPv6. I realise that a lot of the early hype about IPv6 implied it was inherently secure, but hype is hype. A high level of security is not achieved by magic. Having to mess with certificates and key exchange is no easier in IPv6 than it is in IPv4!

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jul 2010 10:41:13 +1200

I agree. Procurement agencies can always elevate IPSec/IKEv2 to
a requirement if they need to, but we should not burden every
low-end implementation with it.

    Brian

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 21 Jul 2010 10:36:36 +0200

Hi Thomas,

> Thoughts?

IPsec and IKE have seen limited deployment on IPv4 networks due to the
lack of E2E there, caused by NAT (client/server model and deployment of
TLS for protecting *applications*). Additionally, I also agree that
IKEv1 specification documents (RFC 2407, 2408 and 2409) were a
pain. PKI were not deployed and this was a problem too. 

Today, IPv6 provides E2E connectivity between end hosts. The work
performed by ipsecme WG on IKEv2 specification to merge previous IKEv1
documents into something consistent (RFC 4306, RFC 4718 and now ikev2bis
document) is impressive. PKI are now widely deployed, even if we still
miss some global credential services. Now, most stacks (windows, linux,
mac os x, ...) have IPv6 and IPsec available. Basically, IPv6, IPsec and
IKE are already available on all devices which can and have any interest
to run those.

Now, the (IMHO only) remaining problems with IPsec and IKE on IPv6
networks are the following:

 - lack of global credential services (if some @google reads this ...).
 - ability for end user to configure things easily, i.e. simple and
   *usable* management interfaces

>    (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has

 - I don't understand why you make a difference between SSL, TLS and
   HTTPS. It's simply TLS.
 - Except for advanced users, SSH serves a single purpose: remote
   connections for administration. I don't know if it should be kept
   here.

In the end, you basically have IPsec at layer 3 and TLS at layer 4. I
should also add the following: we use TLS in a very restricted way on
the Internet today, for client/server communications and in fact mainly
for browser/server communications. Mutual authentication is seldom,
logic and configuration is per apps, ...

>    is not viewed as a good choice for all security needs.

IMHO, the thing is not to mandate the *use* of an *IP security* solution
in people' architectures and products, but to provide the guarantee that
such a compatible IP security solution is available on the different
systems we buy and deploy.

AFAICT, IPsec/IKE is the only IP security solution we have. We know it
works. It's mainly a matter of guaranteed availability, like for
IPv6. If one has the guarantee to find that on all common IPv6 devices,
then you get interoperability and deployment.

A "MUST support IPsec and IKE" would be a step in the good direction.

>    be considered a very strong SHOULD, if not a MUST.

I think the text is well written and captures the main issue, which is
IMHO related to RFC 2119: small devices that cannot run TLS or IPsec/IKE
due to their hardware limitations prevent the use of a "MUST". Because
we do not have another keyword in the context of RFC documents, "SHOULD"
is the only solution if we keep those devices in the global scope of
"IPv6 nodes".

To me, the problem with the "strong SHOULD" is that it will not prevent
anyone to ship an IPv6 system with TLS-enabled apps (i.e. no hardware
limitations) and not IPsec/IKE at all while still claim compatibility
with the standard.

Cheers,

a+

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Jul 2010 09:16:55 -0400

Hi Arnaud.

> TLS for protecting *applications*).

I think there is more to lack of deployment than the above. There are
many reasons why IKEv1 and IPsec are not more widely deployed than
they are.

> Additionally, I also agree that IKEv1 specification documents (RFC
> 2407, 2408 and 2409) were a pain. PKI were not deployed and this was
> a problem too.

> IKE are already available on all devices which can and have any interest

This is way over stated. IKEv2 is just now starting to see
implementations. Usage is even further behind.

I just went to the IPv6 ready logo site and searched for IKEv2 on the
list of devices that have acheived Phase II certification. I didn't
find a single entry. (http://cf.v6pc.jp/logo_db/approved_list_ph2.php)

IKEv2 simply is not ready yet for usage on a significant scale. If you
look at the deployed based of IP devices (or even focussing on those
that support IPv6), very few of them support IKEv2 today.

>    *usable* management interfaces

If there are still significant gaps in our ability to use IPsec and
IKEv2, that again suggests to me that it is premature to mandate it in
all devices. It is simply premature to do so, from an overall
readiness perspective.

>  - I don't understand why you make a difference between SSL, TLS and

OK, I need to clean this up. I could also mention SASL here, HTTP
digest, etc.

>    connections for administration. I don't know if it should be kept

But it is an example of a security technology that is being used to
secure a class of applications, for which IPsec could also be used,
but is not. And I suspect that IPsec will not displace such usage.

> then you get interoperability and deployment.

I agree with this. But I've also come to the conclusion that for a
class of devices, mostly characterized by small footprint and limited
functionality, there are cheaper alternatives to providing security
than requiring the use of IPsec and IKEv2.

E.g., should home gateways be required to support IKEv2 in order for
you to configure it?

> A "MUST support IPsec and IKE" would be a step in the good
  direction.

Well, that is the question for this thread!

> limitations) and not IPsec/IKE at all while still claim compatibility

That is the balancing act we are trying to achieve.

Note though that there are other profiles being developed outside of
the IETF that are focussed on specific deployments or
environments. They are free to mandate IKE even if we do not. E.g, in
the US, the DoD and the USGv6 profiles mandate IPsec and IKEv2. 3GPP
is another example.

But for an IETF recommendation, we have a broader class of devices to
make recommendations for, and a wider range of potential usages.

Thomas

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 21 Jul 2010 17:45:01 +0200

Hi,

> many reasons why IKEv1 and IPsec are not more widely deployed than

What other reasons not listed in my email? ;-)

> that support IPv6), very few of them support IKEv2 today.

In the discussion, I was considering IKE in general. I don't really care
if it is v2 or v1 because I consider the functionality it
provides. Sure, IKEv2 is not already available on all platforms but
IKEv1 is and you should consider the trend for major platforms: Linux
has strongSwan, which interoperates with Windows 7 IKEv2 implementation.
Do you know the pain is was (and still is) to make IKEv1 implementations
interoperate in IPv4 environments?

And for the certification argument, it would be ok to me if there were
equivalent certification program for concurrent solutions (TLS or
whatever). In fact, I would say that the availability of such
certification programs is already an argument that the solution is worth
considering.

Additionally:

  http://www.vpnc.org/testing.html#IPv6Interop
  http://www.vpnc.org/testing.html#IKEv2BasicInterop

> all devices. It is simply premature to do so, from an overall

Those gaps do not prevent the use of IPsec/IKE or the usefulness of the
protocols, they just make it more difficult for real end user. The same
is true on some aspects of IPv6: DNS provisioning, IPv4/IPv6 transition,
availability. The IPsec/IKE aspects are being worked on:
https://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 

The way I see it is that we have security building blocks (IPsec/IKE)
that already work for many and which could easily be provided to many
others, all the more if it is globally deployed. It seems the argument
you have is that it is not ready to ship. I think some successful
companies have previously shipped successful products in "beta" state
and it just increased the use and the work on the products. And I think
IPsec/IKE is now more than in a beta state.

> but is not. And I suspect that IPsec will not displace such usage.

I use both daily. For different things. ssh to get a shell on remote
devices. And IPsec/IKE to protect all kinds of traffic to remote
devices. I will never argue on the usefulness of specific application
security protocols. But their existence is simply not a counterargument
for not having an IP security solution.

> E.g., should home gateways be required to support IKEv2 in order for

To configure it from the inside, no. To access your internal LAN from the
outside, what do you think? Then, making them MIPv6 Home Agents would
simply allow you to be at home everywhere ...

> make recommendations for, and a wider range of potential usages.

I understand your arguments. If people in the working group are ok to
set the security requirements for IPv6 nodes to support the whole scope
of devices (i.e. don't want to make an exception for constrained
devices), then I think your text is the best we can have.

Thanks for your time, Thomas.

Cheers,

a+

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Jul 2010 12:39:26 -0700

Manfredi, Albert E wrote:
> I think this has become a big obstacle to deploying IPv6. I realise
> that a lot of the early hype about IPv6 implied it was inherently
> secure, but hype is hype. A high level of security is not achieved by
> magic. Having to mess with certificates and key exchange is no easier
> in IPv6 than it is in IPv4!

Hmm... 

My admittedly limited perspective is that almost nobody uses IPv6 at home, and in corporate environments there is far more IPsec users than IPv6 users. 

Thus your characterization that IPv6 isn't widely used/deployed because of a MUST implement IPsec seems a bit strange to me.
 
--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Jul 2010 13:04:36 -0700

Thomas,

Please see some comments below:

>From my perspective the cost of implementing IKEv2 on a device is congruent to the cost of implementing any other key management protocol. E.g., TLS is about as complex. So maybe it boils down on whether we want to mandates that a mean to secure the internetwork layer is available on every IPv6 node. I think so.  
 
>    operational practices, etc.

Sure.
 
>    applications, other security protocols will be more appropriate

Fair enough. In which case somebody can choose application or transport layer security instead of network layer security. Still, there is a class of scenarios where network layer security is the best fit, and we should be mandating that these are available for use, when it makes sense.

>    devices?  Personally, I don't think so.

If I'm going to use an iPod to remotely connect to my home network, it would make sense that it supports IPsec to provide a VPN function. That way all IP traffic is protected.

That being said I agree that for constrained devices it might be desirable not to implement IPsec and IKE. The question is, should we lower the node requirements bar for all devices because of constrained devices. I don't think so.
 
>    the IETF say it is required hasn't forced all vendors to implement

If we remove from requirements documents every feature that hasn't been implemented by all vendors, then we could just remove everything. Conversely, if all vendors were implementing every feature of the requirement document, why would we need one in the first place? The point of the requirement document is to recommend implementation of a set of IPv6 features to improve system level interoperability. 

>From my perspective IPsec is only choice for network layer security. There are some scenarios where network layer security is not the best choice to secure a system, and there one can choose to use application or transport layer security. 

We should still make sure that every IPv6 node has means to protect its network layer, and make both IPsec and IKEv2 MUST implement. I'd be fine with documenting an exception for constrained nodes where it is not possible to fulfill the requirements, e.g., "Support of both IPsec and IKEv2 is a MUST for IPv6 nodes, except for constrained devices that cannot support implementations of IPsec and IKE."

--julien

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Jul 2010 16:12:15 -0400

Hi Julien.

Just commenting on your last point..

> We should still make sure that every IPv6 node has means to protect
> its network layer, and make both IPsec and IKEv2 MUST implement. I'd
> be fine with documenting an exception for constrained nodes where it
> is not possible to fulfill the requirements, e.g., "Support of both
> IPsec and IKEv2 is a MUST for IPv6 nodes, except for constrained
> devices that cannot support implementations of IPsec and IKE."

The difficulty with such wording is we now start arguing about what a
"constrained device" is.  This is a judgement call, and is often not
about whether it can be done, but whether it should be done at the
expense of some other feature deemed more valuable to device's main
function. Or by increasing the cost of the device (by adding more
memory, etc.)

I do like the idea of clarifying that network layer security is a good
general thing and that IPsec/IKE is the solution for that. But this
still begs the question in that network layer security is simply not a
requirement for all applications and usages of an IP device (IMO).

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Jul 2010 13:36:56 -0700

Julien,

> That being said I agree that for constrained devices it might be desirable not to implement IPsec and IKE. The question is, should we lower the node requirements bar for all devices because of cons…

From RFC2119 the definition of MUST and SHOULD are:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

The discussion is about changing the required level from MUST to SHOULD.  SHOULD is a strong recommendation.  It says that you should implement IPSEC and IKE except if you have a good reason (e.g., constrained implementation).   This seems appropriate to me.

> We should still make sure that every IPv6 node has means to protect its network layer, and make both IPsec and IKEv2 MUST implement. I'd be fine with documenting an exception for constrained nodes…

That is the definition of SHOULD.

By the way, I talked to a Smart Grid vendor a few weeks ago.  They are using IPv6 exclusively in their AMI network (great news) and using IPSEC to secure the communication.  However, they are not using IKE and instead use manual keys.  That makes a lot of sense for them.  I think this is a good example of what is being discussed.  

Bob

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 21 Jul 2010 15:44:08 -0500

> Behalf Of Thomas Narten

> requirement for all applications and usages of an IP device (IMO).

TLS is great, and is used a lot, because it can be applied on a case by case basis. It is not imposed on the whole network. It is implemented by applications that require security, and not be the rest.

When MUST is specified for IPv6 IPsec, this translates to every device connected to the network, as well as the network itself, MUST support IPsec. For example, that is how the requirement gets passed down by the DoD. Want to do IPv6 for your control network? Fine, but now you need certificates and key exchange, and all of the administrative infrastrucre that goes with these. Where simpler security schemes may have sufficed previously.

So, end systems that may otherwise migrate to IPv6 hesitate. They are discovering all of the additional overhead of IPsec implementation that they never had to worry about before.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 21 Jul 2010 16:04:51 -0500

> From: Sean Siler [mailto:[email-masked]] 

> You are mixing engineering requirements and deployment 
> requirements. Yes , the hardware and software MUST support 
> IPsec. The customer doesn't *have* to do anything. They can 
> use Mickey's Secret Decoder Ring with IPv6 if they want to.

Depends on the customer. My customer's organization says, you're not IPv6 compliant if you don't support IPsec. So individual customers from that organization, and equipment vendors, say "okay, so we will hold off on IPv6." As they have been doing.

Bert

---

From: Sean Siler <[email-masked]>
Date: Wed, 21 Jul 2010 20:53:35 +0000

"When MUST is specified for IPv6 IPsec, this translates to every device connected to the network, as well as the network itself, MUST support IPsec. For example, that is how the requirement gets passed down by the DoD. Want to do IPv6 for your control network? Fine, but now you need certificates and key exchange, and all of the administrative infrastrucre that goes with these. Where simpler security schemes may have sufficed previously."

You are mixing engineering requirements and deployment requirements. Yes , the hardware and software MUST support IPsec. The customer doesn't *have* to do anything. They can use Mickey's Secret Decoder Ring with IPv6 if they want to.

BTW, if anyone knows where I can get an IPv6 enabled Mickey Secret Decoder Ring, let me know. <grin>

Sean

---

From: Mark Smith <[email-masked]>
Date: Thu, 22 Jul 2010 11:51:04 +0930

>    *usable* management interfaces

RFC 5386 / Better-Than-Nothing Security goes some way to addressing
that. Obviously not as secure as properly identified peers, but as the
name says (far) better than nothing.

I also think we should observe what seemed to have happened with the
DECT standards. Encryption was optional, so when I went to try to find
a DECT phone with it, I couldn't easily find one (and didn't). Cryto
does add a cost, however the scales of economy caused by mandating it
reduce that cost.

I'm also not completely sure the embedded platform load concern is a
strong one anymore. The IEEE have mandated 128 bit AES encryption for
the 802.15.4 / LoWPAN standards, and they're targeted at low power
embedded platforms.

So while I think the reasons to loosen the IPsec requirement are
fairly valid, I'd be concerned that it would cause the "DECT
problem" to happen.

---

From: <[email-masked]>
Date: Fri, 23 Jul 2010 18:58:53 +0200

IPsec and IKEv2 are network layer protocols that are available in the security toolkit.
And so are TLS, ssh, Kerberos etc. 

The IETF cannot force the choice of a security protocol on applications or other protocols 
that need security. The choice of using IPsec and IKEv2 is available at all times. But
it may not be the best fit in all cases. SDOs, application and protocol developers should
be free to choose from the available options. An application may be deployed with different
security mechanisms in different environments. A good example is IPsec VPNs as well as SSL VPNs.

Use of IPsec on host devices today is primarily for a single usecase, i.e VPN connectivity. 
IPsec is used within the core of a network for many purposes. Some end-hosts may be constrained
and mandating IPsec/IKEv2 in order to be IPv6 compliant is unwarranted. And other end-hosts 
which do support IPsec/IKEv2 may use it for some use cases and applications. But it should not
be the IETFs role to mandate that it be the security protocol used in all cases. 

Hence a SHOULD require is sufficient in the context of IPv6 node-requirements.

-Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Thomas Narten
Sent: Wednesday, July 21, 2010 3:12 PM
To: Laganier, Julien
Cc: [email-masked]
Subject: Re: Node Requirements: Issue 17 - IPsec/IKE

Hi Julien.

Thomas

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 23 Jul 2010 19:38:51 +0200

Hi,

<[email-masked]> writes:

> IPsec and IKEv2 are network layer protocols that are available in the
> security toolkit. And so are TLS, ssh, Kerberos etc. 

TLS, ssh and Kerberos are available in "the security toolkit" but they
are not network layer protocols. IP and IPsec are.

> The IETF cannot force the choice of a security protocol on
> applications or other protocols that need security.

That's correct and that's not what the node requirements doc is about:
it's about mandating *support*, and not use.

> The choice of using IPsec and IKEv2 is available at all times.

In order for that to be true, you need system that *support* the
protocols, i.e. implement it. This is what you are trying to prevent
even for system that have enough resources.

> But it may not be the  best fit in all cases. SDOs, application and
> protocol developers should be free to choose from the available
> options.

Completely true. And having IPsec and IKEv2 available on a system will
never prevent someone to use TLS. It's even likely they will use the
same libraries/foundations.

> An application may be deployed with different security mechanisms in
> different environments. A good example is IPsec VPNs as well as SSL
> VPNs.
>
> Use of IPsec on host devices today is primarily for a single usecase,
> i.e VPN connectivity. IPsec is used within the core of a network for
> many purposes.

That's the point. Having IPsec/IKE *available* on all nodes leaves room
for the deployment of the protocol for E2E security. Additionally, it
does not prevent at all the use of additional mechanisms. It will never
replace TLS or ssh, because they serve different purposes.

> Some end-hosts may be constrained and mandating IPsec/IKEv2 in order
> to be IPv6 compliant is unwarranted. 

I think we all agree on that. The problem is not IPsec/IKEv2 here.It's
not constrained devices either. It's the fact that we do not have an
easy way (in RFC keywords) to mandate support for all devices if they
can reasonably do it w/o making constrained devices look like they are
not IPv6 nodes because they cannot have it.

> And other end-hosts which do support IPsec/IKEv2 may use it for some
> use cases and applications. But it should not be the IETFs role to
> mandate that it be the security protocol used in all cases. 

Again, I don't understand your position: having IPsec/IKEv2 available on
systems that have sufficient resources to run those does not impose its
*use*. It just guarantees that it is available if you need it.

Cheers,

a+

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 23 Jul 2010 20:19:36 +0200

Hi,

My first choice was (in respect with RFC 2119):
- a MUST for IPsec
Because IPsec is the security architecture for the IP layer.
- a SHOULD for IKEv2
Because,
   o Anti-replay service available for AH and ESP requires automated
SA management (cf. RFC 4301)
   o Regarding scalability/deployment, IKEv2 is useful
   o Some IPv6 nodes may have constraints (e.g. 6lowpan nodes), even
if I believe that constraints, with time and improvement of
technologies, disappear in the end.

but seeing that some people deliberately interpret "SHOULD" as a "MAY"
(i.e. the good technical reason to avoid the implementation of the
protocol is in fact only a political/company/personal - make your
choice - reason), I've decided to change my mind:
- a MUST for IPsec
- a MUST for IKEv2

Best regards.

JMC.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Jul 2010 21:09:35 -0700

> The discussion is about changing the required level from MUST to SHOULD.  SHOULD is a strong recommendation.  It says that you should implement IPSEC and IKE except if you have a good reason (e.g.,…

I agree on these grounds as well.  SHOULD is the best term.  I am
currently going through a project where IPsec on mobile devices has
been ruled-out by the handset manufacturers and application level
encryption will be used to move foreword.

Cameron

---

From: "Laganier, Julien" <[email-masked]>
Date: Sat, 24 Jul 2010 10:42:37 -0700

Hi Thomas,

> function. Or by increasing the cost of the device (by adding more

If we make it a SHOULD it is going to be a judgment call as well when one has to decide whether to implement IPsec or not on a given devices. And people will find themselves arguing whether there "exist valid reasons in particular circumstances to ignore" the requirement to support IPsec.

Also, we might actually not need to argue for the majority of cases since there are plenty of arguably unconstrained devices, such as my cell phone that embeds a 200MHz modem processor and a 1GHz application processor. 

So if we could come up with processing power and memory values under which a device is considered constrained (e.g., less than 50MHz and 8MB memory) and IPsec downgrades from a MUST to a SHOULD it seems to me we'd have cleared the way.

> requirement for all applications and usages of an IP device (IMO).

Agree. But having a MUST gives choice to customers/designers. They can choose to use network layer security or not, because it is implemented.

--julien

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jul 2010 09:08:02 +1200

On 2010-07-25 05:42, Laganier, Julien wrote:
...
> So if we could come up with processing power and memory values under which a device is considered constrained (e.g., less than 50MHz and 8MB memory) and IPsec downgrades from a MUST to a SHOULD it…

That is truly an engineering decision for a given implementor.
I can't imagine any values we could choose today that would still
be valid twenty years from now; and we need to think of this RFC
still (perhaps) being used in twenty years.

It's very clear from the IPv4 market, where IPsec/IKE(v2) have
exactly the same value from a security view, that the industry
sees this as a SHOULD requirement. Apart from a vain attempt to
validate the myth that IPv6 is in some way more secure than IPv4,
I can't see any advantage in deviating from a straightforward
RFC 2119 SHOULD. Vendors will do what they will do.

    Brian

---

From: <[email-masked]>
Date: Sun, 25 Jul 2010 09:05:43 +0200

To reply to Julian's mail.  I think the issue is more about deployments rather
than devices.  I know plenty of low-powered devices that have successfully implemented
/ deployed IPsec, when needed. However, I think the real issue is that in many
circumstances, people feel that deployment specific issues are motivation not to
implement / use IPsec.  Why write the code if it will never be used is often the 
comment I have heard.  

I would think it would be good if most hosts could support IPsec, for many reasons,
but there will be some special purpose networks & devices that will never need
IPsec.  I would like it if we could rather discuss the use of IPsec and the requirements
for implementing IPsec in nodes more on a deployment basis rather than a hw 
specific reason.

My thinking is that if a node will need to participate in secure transaction, have
and send data that might need to be protected, and to harden the node against
certain threat vectors, than a MUST is entirely appropriate.  If there are other
mechanisms that are used for security, including transport layer security, which
are more appropriate and cover the threat vectors that the node may be susceptible
to, then that may be more appropriate.  If, for some reason, the node will have a 
specific deployment where security is not needed for any reason, then the requirement
drops to a SHOULD.  I would still suggest it is SHOULD because the person writing
the SW stack will never know all of the scenarios that the node will be deployed.

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Brian E Carpenter
> Sent: Saturday, July 24, 2010 2:08 PM
> To: Laganier, Julien
> Cc: Thomas Narten; [email-masked]
> > So if we could come up with processing power and memory values under
> which a device is considered constrained (e.g., less than 50MHz and 8MB
> memory) and IPsec downgrades from a MUST to a SHOULD it seems to me
> we'd have cleared the way.
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 2010 08:36:26 +0200

I would like to add my personal observations....

> many reasons why IKEv1 and IPsec are not more widely deployed than

There is little in E2E, or P2P in the application space. Maybe in the 
gaming community.  And what little there is has developed its own 
security model for many reasons, one big one being to have assurance 
that security IS in place.  Plus in v4 there has always been the NAT 
traversal challenge for security.

There seems to be no real IKEapi for applications to be IKE aware.  Thus 
an application has no way to bring up the E2E security, thus 
applications go it alone.  I may be wrong here and missed the adding of 
an IKEapi.

Along with the API is a mechinism to discover which hosts can be 
secured.  This is more than they have IKE and IPsec, they have to be 
configured with matching policy.  If one is using RSA and the other 
ECDSA will it work?

Now even when the answers to these questions are YES!, there is the 
marketing to the general apps world.  Can you get Bittorrent to switch 
to IPsec when run over IPv6?  What about some big gaming app?

Usage is tied into usablity.  I worked this out from my own research 
last fall.

>> A "MUST support IPsec and IKE" would be a step in the good
>>      
>    direction.
>