Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00

From: Shoichi Sakane <[email-masked]>
Date: Tue, 08 Mar 2011 10:22:30 +0900

I strongly support this draft.  It must be useful for the implementers
to develop IKEv2 to enable a kind of m2m communication with IPsec.

This draft describes a scenario to use IKEv2 for a minimum specification.
The document only allows one side to be a responder.  I would like to a
little extend it.  That means it allows both sides to be a responder.
Here is an example scenario, in a scenario of smart metering, both a
meter and a server have a power line, but the power consumption should
be lesser as much as possible.  The network is lossy.  The resource of
the device is typically constrained, for example, memory or physical size.

Shoichi Sakane

On 2/23/11 11:44 PM, Tero Kivinen wrote:
> I wrote draft about the minimal IKEv2 implementation. It does not try
> to change anything in the RFC5996, it just explains what kind of
> implementation would be useful in some machine to machine
> communication scenarios and which would still be complient to the
> RFC5996 (with an exception of not supporting certificates).
>
> The document contains 44 pages, from which the actual protocol
> description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the
> document is payload format diagrams copied from RFC5996.
>
> This document is meant for people who are not using IPsec for VPNs or
> similar, but are thinking whether IPsec and IKEv2 could be used in for
> small devices for machine to machine communications.
>
> ----------------------------------------------------------------------
> A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has
> been successfully submitted by Tero Kivinen and posted to the IETF
> repository.
>
> Filename:	 draft-kivinen-ipsecme-ikev2-minimal
> Revision:	 00
> Title:		 Minimal IKEv2
> Creation_date:	 2011-02-23
> WG ID:		 Independent Submission
> Number_of_pages: 44
>
> Abstract:
> This document describes minimal version of the Internet Key Exchange
> version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for
> performing mutual authentication and establishing and maintaining
> Security Associations (SAs).  IKEv2 includes several optional
> features, which are not needed in minimal implementations.  This
> document describes what is required from the minimal implementation,
> and also describes various optimizations which can be done.  The
> protocol described here is compliant with full IKEv2 with exception
> that this document only describes shared secret authentication (IKEv2
> requires support for certificate authentication in addition to shared
> secret authentication).
>
> This document does not update or modify RFC 5996, but provides more
> compact description of the minimal version of the protocol.  If this
> document and RFC 5996 conflicts then RFC 5996 is the authoritative
> description.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Mar 2011 23:30:36 +0200

I also agree that this draft is useful, and I support its going forward, either as a WG document or as an individual document. 

While data communications may originate from either side (sensor notifies controller, controller queries sensor, controller sends command to actuator), I think it is reasonable to require that IKE be initiated from the "thing", for two reasons:
 1. It cuts down the required code almost in half
 2. The "things" often sleep for extended periods of time, so you can't depend on them being able to respond.

There are two things I'm wondering about, though. Why is this draft written like a mini-RFC5996, instead of just referencing 5996 and describing a profile. You could skip all of Appendix A and much of the explanation in section 2. 

Also, what happens with SA expiry?  According to section 2.1, the "thing" Cannot send delete payloads in Informational exchanges. I guess it could just create a new IKE SA if its policy says that the old one has expired. But if the SA expires first on the controller, either the "thing" is sleeping and will miss the DELETE payload, or it's not sleeping, and will ignore the DELETE payload. Either way, you're stuck with an SA that exists on the "thing" but not on the controller.

I can think of three ways to avoid this: You can require that SA lifetimes be always shorter on the "thing" than on the controller. You can require them to explicitly send SA lifetimes. Or you can require them to implement failure detection.

Yoav

On Mar 8, 2011, at 3:22 AM, Shoichi Sakane wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Mar 2011 16:52:19 +0200

Shoichi Sakane writes:
> The document only allows one side to be a responder.

More correct way is to say, that this document only describes the
node which is always the initiator of the communication. 

> I would like to a little extend it. That means it allows both sides
> to be a responder.

To be able to act as responder requires to take more features from the
full IKEv2, and very soon you are better of with full IKEv2
implementation.

For example to be able to act as responder usually means that you need
to have some kind of policy decision module, i.e. which when given the
identity of the initiator will check whether that peer is allowed to
create connections, use specific algorithms, or do other things.

In the initiator end it is usually simple, as you simply only offer
the things you support, and when you are initiating the connection you
already have your policy specified. 

> meter and a server have a power line, but the power consumption
> should be lesser as much as possible. The network is lossy. The
> resource of the device is typically constrained, for example, memory
> or physical size.

I would except that the smart meter meter would be the one using
implementation like described in draft-kivinen-ipsecme-ikev2-minimal,
and the server where that meter connects to needs to support full
IKEv2. For example usually there is multiple meters for each server
meaning that the server needs to support multiple simultaneous IKEv2
SAs, IPsec SAs, and it needs to do policy lookups based on the
identity of the meter device etc.

In the server end there is also some features of the IKEv2 which can
be left out (for example configuration mode, nat traversal (depending
on the network), etc), but in this document I tried to concentrate on
the very minimal implementation. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Mar 2011 17:07:02 +0200

Yoav Nir writes:
> There are two things I'm wondering about, though. Why is this draft
> written like a mini-RFC5996, instead of just referencing 5996 and
> describing a profile. You could skip all of Appendix A and much of
> the explanation in section 2.

One of the reasons is that I wanted the document to include things
that implementor needs. If I would require implementor to read RFC5996
in addition to this draft, that would not help them to make
implementations.

Now the current document tries to be short enough that people will see
that "ok, this is something we can implement" especially when they see
that the most of the pages is simply payload format descriptions,
which they can simply read when they are actually writing that payload
encoding/decoding, and otherwise skip over.

> Also, what happens with SA expiry?  According to section 2.1, the
> "thing" Cannot send delete payloads in Informational exchanges.

SA expiry is not an required feature of IKEv2. It is completely
possible that IKEv2 node looses IKE SA without sending delete
notification, and starts from the beginning.

For the minimal devices they can completely forget the IKEv2 SA (and
IPsec SA) when they go to sleep, and recreate it every time they wake
up, i.e. the sleeping is more less a "turning off" and "booting up
again".

Or they can keep the IKE SA and Child SA up and assume the server will
is configured so it will keep it up, and do not expire the SA based on
the time.

Those SAs usually has so little data going through them that there is
no need to rekey SA based on the time.

For some cases there might be more data (for example video feed from
camera), but in that case minimal implementation is not enough
anymore, as in that case you do usually need support for rekeys.

> I guess it could just create a new IKE SA if its policy says that
> the old one has expired. But if the SA expires first on the
> controller, either the "thing" is sleeping and will miss the DELETE
> payload, or it's not sleeping, and will ignore the DELETE payload.
> Either way, you're stuck with an SA that exists on the "thing" but
> not on the controller.

If the "thing" is configured so that it keeps IKE SA up, then the
server should configured so that it does not expire the SA. Most of
those protocols include reply anyways, so if no reply is received the
"thing" can start over, i.e remove the IKE SA and recrete it from the
scratch and then try again.

> I can think of three ways to avoid this: You can require that SA
> lifetimes be always shorter on the "thing" than on the controller.

Or remove the concept of lifetimes, as they are not needed here. 

> You can require them to explicitly send SA lifetimes.

Lifetimes in IKEv2 is local matter, and they are never transmitted. 

> Or you can require them to implement failure detection.

No need for that.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Mar 2011 22:58:35 +0200

Hi Tero.

IKEv2 has an underlying assumption that peers are always available to respond (for example to liveness check). If you're doing a special profile for minimal implementation that are not always available (because they're in a low-power mode), you should also profile the server that talks to them. These should include:
- no liveness checks, as these would lead to timeouts and dropping of SAs.
- no initiating (this I think violates 4301, but it's OK if IKE retransmits a couple of times and fails)

One of the use cases that we hear about is small battery-powered sensors and actuators communicating via 802.15.4 at rates of 10-20 kbps with 6lowpan. At those rates, it takes several seconds to set up an IKE and child SA, and that is not fast enough for many uses. So I think the general way of doing things should be that the "things" keep the SAs when they go to sleep.

Most IKE products that I know of don't keep SAs forever. Looking at the StrongSwan code, it looks like the longest time you can keep an IKE or IPsec SA is 1 day. The problem is that the peer might be sleeping when the SA expires on the server, and we don't want to wait for a timeout when it wakes. So there has to be a pre-agreement on lifetime. This doesn't have to be negotiated using AUTH_LT, though. You can specify in your draft that SAs last 24 hours.

Then you have to deal with failure detection. A failure of the server would mean that for 24 hours all devices that try to communicate time out using the old SA, before they restart. It may be OK to live with it, but this should be stated in the draft.

Anyway, the thing that's really missing is requirements or profile for the server, as you can't take a normal IKE implementation and have it work well with those minimal implementations.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Mar 2011 17:06:46 +0200

Yoav Nir writes:
> IKEv2 has an underlying assumption that peers are always available
> to respond (for example to liveness check).

Can you point me to that in RFC5996, I think I might have missed that.
I am under the understanding that either end of the IKEv2 protocol can
crash/shutdown/go silent at any point and after that point it will not
answer to any IKEv2 messages anymore and this is allowed by the
protocol and all complient implementations should be able to cope with
it. 

> If you're doing a special profile for minimal implementation that
> are not always available (because they're in a low-power mode), you
> should also profile the server that talks to them.

Note, that the draft-kivinen-ipsecme-ikev2-minimal-00 does explicilty
mention how to respond to the DPD etc message, i.e. the minimal
implementation implemented based on the draft do know how to answer to
requests sent by the server, provided the device is still active.
After the device is powered off, it of course cannot answer anymore.

For example the appendix B.1 describes one additional useful feature
for such devices, i.e the ability to send delete notification to the
IKEv2 SA before going to sleep so server end does not waste resources
while trying to do DPD, and then noticing that other end has
disappeared, and tearing down the IKEv2 SA. 

> These should
> include:

Liveness checks are optional anyways and only performed if the device
thinks there is some reason to belive that the other end is no longer
up. No sane IKEv2 implementation should ever implement periodic
liveness checks, and I do agree that using periodic liveness checks
breaks lots of other things too, and in my opinion rfc5996 should have
prohibited them. Unfortunately some people go for the easy
implementation route, and do implement them and then we do have all
kind of problems.

>   retransmits a couple of times and fails)

I do not think RFC4301 forbids to have responder only setups. For most
cases that is the most common setup anyways, as for road warriors the
SGW cannot initiate to the road warrior as it does not know its IP
address. If the device is up and server tries to create new IPsec SA,
then it will answer NO_ADDITIONAL_SAS as is allowed by the RFC5996. 

Anyways neither one of those affects the implementation of the other
end at all, only to their policy setup and configuration, and in
general configuration of the SGW depends so heavily about the scenario
that I see no point of start documenting or dictating what kind of
policy is allowed or not allowed in the different scenarios. 

> One of the use cases that we hear about is small battery-powered
> sensors and actuators communicating via 802.15.4 at rates of 10-20
> kbps with 6lowpan. At those rates, it takes several seconds to set
> up an IKE and child SA, and that is not fast enough for many uses.
> So I think the general way of doing things should be that the
> "things" keep the SAs when they go to sleep.

Speed of 10-20kbps means the IKEv2 setup time is will be less than
second (not counting crypto calculations), as the actual data
transmitted during the initial setup is less than 1kB.

Anyways I would except that in such environments the minimal device
could be configured to keep the IKEv2 SA and IPsec SA up, and the
other end should be configured accordingly for that environment. 

> Most IKE products that I know of don't keep SAs forever. Looking at
> the StrongSwan code, it looks like the longest time you can keep an
> IKE or IPsec SA is 1 day.

And I assume it would be around few lines of code change to remove
that limit if someone is forced to use such implementation. At least
our product can be configured to keep SAs up for long time (even years
depending on the platform).

Also RFC4301 mandates support for both time and byte count based
lifetimes, and allows either one of them or both of them to be
configured. If you have configured SA to use only byte lifetimes, then
the time lifetime should not be active at all.

> The problem is that the peer might be sleeping when the SA expires
> on the server, and we don't want to wait for a timeout when it
> wakes. So there has to be a pre-agreement on lifetime. This doesn't
> have to be negotiated using AUTH_LT, though. You can specify in your
> draft that SAs last 24 hours.

24 hours is way too short for some uses. I would expect it to be
around month or a year or so. The data transfer on those links is so
slow that before they reach for example 2^32 bytes it takes long time
(more than month with your example link). To reach byte count where
AES cipher really needs to be rekeyed because we have transmitted too
much data over it it takes almost forever :-)

> Then you have to deal with failure detection. A failure of the
> server would mean that for 24 hours all devices that try to
> communicate time out using the old SA, before they restart. It may
> be OK to live with it, but this should be stated in the draft.

As my draft does not specify any lifetime nor does it assume that SA
is up all the time, I do not think there is need to add text specific
to one scenario, especially when most of that would be text describing
what kind of configuration might be required in some scenarios.

I think that text belongs more or less to the exact profile document
for that specific environment, i.e. for example the smartmetering
profile document or similar could specify that no server initiated DPD
is ever done, and lifetime of the SA should be assumed to be more than
a year.

> Anyway, the thing that's really missing is requirements or profile
> for the server, as you can't take a normal IKE implementation and
> have it work well with those minimal implementations. 

The idea of the draft is that it DOES NOT require any requirements or
profiling of the server. It works with standard normal complient IKEv2
implementation without any changes.

Depending on the scenario some specific configuration of the server is
REQUIRED, for example it needs to be configured to allow pre-shared
key authentication using the ID sent by the minimal node, and it must
be configured to support AES, and its lifetime policy needs to be
configured to match the environment where this setup is used.

None of those affect the protocol, they are only configuration options
which usually are already there in the complient full implementation
of IKEv2. 
-- 
[email-masked]