Subject: Re: Last Call: <draft-ietf-lwig-ikev2-minimal-02.txt> (Minimal IKEv2) to Informational RFC (fwd)

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Sep 2015 10:32:11 -0400 (EDT)

> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-lwig-ikev2-minimal-02.txt> (Minimal IKEv2) to 
> Informational RFC
> Date: Fri, 18 Sep 2015 07:27:27 -0700
> 
> 
> The IESG has received a request from the Light-Weight Implementation
> Guidance WG (lwig) to consider the following document:
> - 'Minimal IKEv2'
> <draft-ietf-lwig-ikev2-minimal-02.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-10-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

I hadn't seen this document until now. I've read the document and have some
comments that might require another iteration. Sorry that I did not see
this document before.

- The title is a bit misleading. This is not a "minimal IKEv2 implementation".
   It is a "minimal IKEv2 client implementation". I would like to see
   that more clearly specified in the title and abstract so it becomes
   clear that two "minimal IKEv2" implementations cannot establish an
   IKEv2 connection with each other.

- Support for sending an empty INFORMATIONAL message is included. I
   assume this is to allow full implementations to do liveness probes.
   However, if the server this client connects to is restarted, the
   client, especially if it only sends answerless data like syslog UDP
   packets, has no way of finding out it is sending un-decryptable
   messages. And due to minimal ikev2, the server cannot initiate to
   the client to recover from this situation. So either this limitation
   should be mentioned, or the spec should also include the minimal client
   sending empty INFORMATIONAL messages for liveness check.

- It would be nice if the document would add a notification message, so
   it can convey via a notification payload that it is a "minimal IKEv2
   client". This will help diagnosing issues later when people
   incorrectly try to run these clients using impossible configurations.
   Such notification could also help the server in treating these clients
   as "INITIAL CONTACT" clients.

- It would be nice if the document could state minimal ikev2 also
   supports RFC 7619 (AUTH NULL) support, which uses the PSK method as
   well so basically no new code needs to be added to support this. This
   could increase the usage of minimal ikev2 implementations for Opportunistic
   Security against pervasive monitoring.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2015 15:12:43 +0300

>    IKEv2 connection with each other.

More exactly minimal IKEv2 initiator implementation.

Changed the title to "Minimal IKEv2 Initiator Implementation" and
modified abstract to say that minimal do require more complete
version for the other end:

Abstract

   This document describes minimal initiator 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 describes mainly shared secret
   authentication (IKEv2 requires support for certificate authentication
   in addition to shared secret authentication).  This minimal initiator
   implementation can only talk to the IKEv2 implementation which
   supports also acting as responder, thus two minimal initiator
   implementations cannot talk to each other.

>    assume this is to allow full implementations to do liveness probes.

No, it is included as it is mandatory feature of the IKEv2, and it is
not limited only to the empty INFORMATIONAL messages, the full IKEv2
server can also send other kind of Notification payloads inside the
INFORMATIONAL exchanges, and minimal version will ignore them. The
minimal version still needs to respond to them with empty
INFORMATIONAL message, as otherwise it would violate the IKEv2
protocol. 

>    sending empty INFORMATIONAL messages for liveness check.

In the use cases we assumed that device is sleeping most of the time,
and during the sleeping it will forget all state, including IKEv2 SAs.
This is also required, as while the device is sleeping the server
might do liveness check, and delete the IKEv2 SA anyways. So every
time the device wakes up it creates IKEv2 SA again. I.e what is
described in the B.1.

I now made it more clear in the use cases section:

   Those devices are usually sleeping long times, and only wakes up
   because of user interaction or periodically.  The data transfer is
   always initiated from the sleeping node and after they send packets
   there might be ACKs or other packets coming back before they go back
   to sleep.  If some data needs to be transferred from server node to
   the small device, it can be implemented by polling, i.e. small node
   periodically polls for the server to see if it for example have some
   configuration changes or similar.  While the device is sleeping it
   will not maintain the IKEv2 SA, i.e., it will always create the IKEv2
   SA again when it wakes up.  This means there is no need to do
   liveness checks for the server, as after the device wakes up again
   the minimal implementation will start from the beginning again.

>    as "INITIAL CONTACT" clients.

As those clients are complient IKEv2 peers, I do not think there is
need for that. If client want them to be treated as INITIAL CONTACT
clients, they can add that notify, or the server might be configure to
have very short timeouts for resource cleanup for them.

I do not think there is need for such notify. 

>    Security against pervasive monitoring.

As this document describes minimal IKEv2 initiator implementation
using PSK, that would mean that the PSK will authenticate both ends,
so there is no point of oding AUTH NULL. Also AUTH NULL would require
more code, as it is using different Authentication Method number.

Yes, the AUTH NULL is usefull in cases where the initiators have raw
public key to authenticate initiator to the server, but initiator does
not care who he sends data to, thus does not require server to be
authenticated.

Added following paragraph to the end of B.2:

   In these setups it might be possible that the authentication of the
   server is not needed at all.  If the minimal device is sending for
   example sensor information to the server, the server wants to verify
   that the sensor is who he claims to be using raw public keys, but
   sensor does not really care who the server is.  In such cases the
   NULL authentication method ([RFC7619]) would be useful, as it allows
   devices to do single-sided authentication.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Sep 2015 11:05:11 -0400 (EDT)

On Tue, 22 Sep 2015, Tero Kivinen wrote:

> Changed the title to "Minimal IKEv2 Initiator Implementation"

While I'm normally the first to call out initiator/responder because
ipsec is a peer protocol and not a client/server protocol, in this case,
because you are removing responder code, it is really a client
implementation now. So I do think "client" is more descriptive than
"initiator" in this case, but I won't fight you over it.

> INFORMATIONAL message, as otherwise it would violate the IKEv2

I am confused. Sure, _responding_ to an INFORMATIONAL is mandatory in
IKEv2, so minimal IKE must also do it. But why do you need support
for _sending_ an INFORMATIONAL? Or did you mean "Support for sending an
empty INFORMATIONAL message" only as an IKE RESPONDER?  If so, you
should clarify that. If you do mean it should support sending
INFORMATIONAL IKE REQUESTs, you should explain why (and then also
explain related to the below paragraph, why then not support
Delete/Notify)

>   the minimal implementation will start from the beginning again.

So in your use case, I don't understand why the minimal ike client
doesn't just send a Delete/Notify to tear down the IPsec SA. Possibly
you don't want to support sending IKE INFORMATIONAL REQUEST packets?

And while you changed your use case, you did not actually address the
problem I described above for those clients that do keep an IPsec SA
open. I still think it would be good to mention, and possibly recommend
that minimal IKE clients always setup a new IKE and IPsec SA to prevent
my problem scenario.

> need for that.

Well no. they cannot detect that the remote endpoint got rebooted other
than by pre-emptively restarting the SA from scratch.

> If client want them to be treated as INITIAL CONTACT

> I do not think there is need for such notify.

Even if the server uses very short timeouts, what will it do? Send a
Delete/notify? The minimal ike client cannot process that informational
message? Worse, your spec makes it return an empty informational
response which is indistinguishable from the response of a successfull
IKE SA delete, which is also an empty informational. So short timeouts
would make the situation worse - it would be like the remote gateway
crashed all the time without the client being able to recover. The only
short cut I can see here is if the minimal IKE client treats all
incoming informational messages as fatal, and deletes the IKE SA with
the IPsec SA. So perhaps say that?

> more code, as it is using different Authentication Method number.

That's stretching the meaning of "require more code" :)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Sep 2015 11:23:11 +0300

Paul Wouters writes:
> for _sending_ an INFORMATIONAL?

In the draft there is only requirement for replying with empty
INFORMATIONAL response to the requests. No support for INFORMATIONAL
requests is required.

> Or did you mean "Support for sending an
> empty INFORMATIONAL message" only as an IKE RESPONDER?

Where is that text? I cannot find it in the draft. 

> If so, you should clarify that. If you do mean it should support
> sending INFORMATIONAL IKE REQUESTs, you should explain why (and then
> also explain related to the below paragraph, why then not support
> Delete/Notify)

There is no requirement for sending INFORMATIONAL IKE REQUESTS in the
draft from the initiator / client, so it would be bit hard to explain
what you ask for.

Can you tell me which part of the draft has caused you to be confused?

In section 2.2 we clearly state:

   Minimal implementation MUST be able to reply to INFORMATIONAL request
   by sending empty response back:

I.e. we only reply to requests by sending empty response back. No
requirement for sending requests is for minimal clients. 

> you don't want to support sending IKE INFORMATIONAL REQUEST packets?

Yep. And sending those are not mandatory, and the server must be able
to cope even if we do not send those. To make the draft really minimal
we left that out.

But on the other hand it was added to the B.1 as it is one of the
useful extensions to implement. 

> that minimal IKE clients always setup a new IKE and IPsec SA to prevent

Such implementation would no longer be minimal, thus it would be
something bit more than minimal implementation, but not yet full
implementation. That is one of the reasons I do not want to have
notify specifying that client is minimal implementation, as the level
of minimalness will be different in different cases. Some implementors
will implement really the bare minimal. Some will also add support for
sending delete notifications. Some use Raw public keys etc.

> than by pre-emptively restarting the SA from scratch.

Yes, and they cannot cope with IP-address changes, as there is no
MOBIKE support, they cannot work across NATs, as there is no NAT
traversal, and so on. There is lot of things minimal implementations
cannot do, but for the described use case it is useful, and it is
still complient to the IKEv2 (with one exception that it does not
support certificates).

The use case is to wake up, create IKE and IPsec SA, send few packets,
go back to sleep. In most cases the send few packets, is really send
few packets, and got some kind of ack back, so if there is no ack, the
client can try again little bit later (i.e. instead of going to sleep
for an hour, only sleep for minute, and then try again).

> Even if the server uses very short timeouts, what will it do?

After timeout it will do liveness check, i.e., send empty
INFORMATIONAL request to the client. If client is still awake and IKE
SA is there, it will reply with empty INFORMATIONAL response to it. If
not, the server will resend message until it times out, and then
deletes the IKE SA. 

> Send a Delete/notify?

It can also do that, but as minimal implementation will ignore the
delete, there is no point of that. It should start with liveness check
first. 

> The minimal ike client cannot process that informational message?

Section 2.2 do require minimal implementations to be able to receive
INFORMATIONAL exchanges, and reply to them with empty INFORMATIONAL
response.

> Worse, your spec makes it return an empty informational response
> which is indistinguishable from the response of a successfull IKE SA
> delete, which is also an empty informational.

Yes. But server should only do that after liveness check.

> So short timeouts would make the situation worse - it
> would be like the remote gateway crashed all the time without the
> client being able to recover. The only short cut I can see here is
> if the minimal IKE client treats all incoming informational messages
> as fatal, and deletes the IKE SA with the IPsec SA. So perhaps say
> that?

No, as that would make liveness checks from the server cause the
client to restart. 

> That's stretching the meaning of "require more code" :)

We we are talking about devices having few kB of memory, every single
bit count... 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Sep 2015 13:49:43 -0400 (EDT)

On Wed, 23 Sep 2015, Tero Kivinen wrote:

Tero,

Thanks for the feedback. ExecSum: I think the document is fine. I have
some small comments left and a few spelling/grammer changes.

> Where is that text? I cannot find it in the draft.

You are right. I got confused by the email text. So the delete issue
I raised is not a problem. Thanks for the clarification on that.

> sending delete notifications. Some use Raw public keys etc.

I'm fine with that being a requirement of minimal ike. It would still be
useful to mention this issue, and recommend that if the minimal ike
client wakes up from sleep, that it always starts a fresh new IKE SA
negotiation.

> for an hour, only sleep for minute, and then try again).

Okay, understood. Although perhaps then you can clarify this by saying
the use case is "to wake up, create IKE and IPsec SA, send few packets,
delete all state and go back to sleep".

> No, as that would make liveness checks from the server cause the

True. Okay forget about liveness and deletes. I take it back and agree
that this is out of scope for minimal clients.

Some remarks about specific text:

    In these calculations, IDi' and IDr' are the entire ID payloads
    excluding the fixed header and the Ni, and Nr are only the value, not
    the payload containing it.

This paragraph defines IDi' but that definition is already used above
it. Can we move this paragraph to above the first use of IDi'

    GenIKEHDR = [ four octets 0 if using port 4500 ]

since NAT-T is not supported, this never happens. Should it be left out
of the description? Same for the next occurance.

    Note, that INFORMATIONAL and CREATE_CHILD_SA requests might contain
    unsupported critical payloads, in which case complient implementation
    MUST ignore the request, and send response message back having the
    UNSUPPORTED_CRITICAL_PAYLOAD notification.

That's a little weird, as most core IKEv2 payloads from the base RFC
7296 are assumed critical (I thought even without a critical flag) .
And if these clients do not support them, they do not know that these
are critical payloads?

I am undecided on what is better, UNSUPPORTED_CRITICAL_PAYLOAD or
NO_ADDITIONAL_SAS.

The remainder are grammar/spelling nits:

    The minimal implementation of IKEv2 only uses first two exchanges

first -> the first

    called IKE_SA_INIT and IKE_AUTH.  Those are used to create the IKE SA

those -> these

    and the first child SA.  In addition to those messages minimal IKEv2
    implementation need to understand CREATE_CHILD_SA request so it can
    reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to
    it, and understand INFORMATIONAL request so much, it can reply with
    empty INFORMATIONAL response to it.

In addition to those messages minimal IKEv2 implementations need to
understand the CREATE_CHILD_SA request enough to generate an
CREATE_CHILD_SA IKE Response message containing the NO_ADDITIONAL_SAS error notify.
It needs to understand the INFORMATIONAL IKE Request message enough to generate
an empty INFORMATIONAL IKE Response message.

    Minimal implementation need only support of being initiator, so it
    does not ever need to send any other request as one IKE_SA_INIT, and
    one IKE_AUTH message.

Minimal IKEv2 implementations only need to support the role of initiator
and only ever need to send out IKE Request messages for the IKE_SA_INIT
and IKE_AUTH exchange.

    As those messages have fixed Message IDs (0
    and 1) it does not need to keep track of its own Message IDs for
    outgoing requests after that.

As the IKE_SA_INIT and IKE_AUTH exchange messages have a fixed  Message
ID (0 and 1 respectively), Minimal IKEv2 implementations do not need to
keep track of their own Message IDs. For IKE Response Message IDs, the
Message ID of the received IKE Request is used.

    or empty notifications replies

or empty notification replies

    can always answer to request coming in, with the same Message ID than
    what the request had

See my above added sentence that replaces this one.

    Incoming IKEv2 packets are mapped to an IKE SA only using the
    packet's SPI, not using (for example) the source IP address of the
    packet.

    As minimal implementation usually has only one host where it
    connects,

I'm not sure if this remark has any value - especially since the latter
sentence states it will only support one concurrent IKE and IPsec SA.
There isn't even "mapping" happening.

    In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and
    the proposed Traffic Selectors for the proposed Child SA in the TSi
    and TSr payloads.  The responder replies with the accepted offer in
    an SAr2 payload, and selected Traffic Selectors.

In the IKE_AUTH Request message, the initiator sends the SA offer(s) in
the SAi2 payload and the proposed Traffic Selectors for the Child SA in the
TSi and TSr payloads. The responder replies with the accepted offer in
an SAr2 payload and with the selected Traffic Selectors.

    In the wildcard case the server quite often narrow the range down

narrow -> narrows

    Using
    single IP address pair as a traffic selectors when sending IKE_AUTH
    will simplify processing as then server will either accept that pair
    or return error.

Using a sigle IP address pair as the Traffic Selectors when sending the
IKE_AUTH Request will simplify processing as the responder will either
accept the IP address pair or return an error.

    If wildcard ranges are used, there is possibility
    that server narrows the range to some other range than what was
    intended.

If wildcard ranges are used, there is a possibility that the responder
will narrow the Traffic Selector range to range that is not acceptable
by the initiator.

    which can be ignored by minimal implementation.

"by a minimal implementation" or "by minimal implementations"

    but any payload unknown to minimal implementation

"minimal implementation" or "minimal implementations"

    notification payloads which can be ignored by minimal implementation.

"a minimal implementation" or "minimal implementations"

    that is quite commonly sent by the minimal implementation.

by a minimal implementation.

    that the initiator does not have any other IKE SAs between them

that the initiator does not have any other IKE SAs between it and
the responder.

    they can be deleted.

those can be deleted by the responder.

    As minimal implementation does not delete
    IKE SAs by sending IKE SA delete, this will help server to clean up
    leftover state.

As minimal implementations delete IKE SAs without sending IKE SA delete
requests, this will help the server to clean up leftover state.

    Responder might also reply with IKE_AUTH response packet which do not
    contain payloads needed to set up Child SA (SAr2, TSi and TSr), but
    contains AUTH payload and an error.  As minimal implementation
    probably do not support multiple SAs nor sending the CREATE_CHILD_SA
    exchanges the IKE SA is useless for initiator.

The responder might also reply with an IKE_AUTH response packet which
does not contain the payloads needed to set up a Child SA (SAr2, TSi and
TSr) and instead contain an AUTH payload and an error. Minimal
implementations that do not support the CREATE_CHILD_SA exchange cannot
recover from this scenario.

    Minimal implementation MUST be

Minimal implementations MUST be able to reply to INFORMATIONAL requests
by sending back an empty INFORMATIONAL response.

    Minimal implementation also MUST be able

Minimal implementations MUST be able

    Typical implementation will reject

Here you suddenly waiver and add breathing room for various kind of
minimal implementations. But you have already defined it as not
supporting CREATE_CHILD_SA, so you should stick to that here:

Minimal implementations do not support CREATE_CHILD_SA requests and MUST
reply to those with a CREATE_CHILD_SA reply containing the NO_ADDITIONAL_SAS
error notify payload.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Sep 2015 13:57:40 +0300

> delete all state and go back to sleep".

I currently have following text:

      While the device is sleeping it will not maintain the IKEv2 SA,
      i.e., it will always create the IKEv2 SA again when it wakes up.

I think that should be enough?

> it. Can we move this paragraph to above the first use of IDi'

Done, and changed the paragraph to say "In following calculations,
..." and moved it before the "The initiator signs ..." paragraph.

> of the description? Same for the next occurance.

Yes. Removed.

> And if these clients do not support them, they do not know that these

Minimal clients will understand all payloads in the base IKEv2, in
such extend that it knows it can ignore them. I.e. if it receives
Delet, Notify or Certificate Payloads, it will simply ignore them.
This is how it is specified in the RFC7296. So because of that it does
not need to say it does not support them.

In most cases there is no need to put the critical payload on any of
the newly defined payloads. Most of the time when new extensions to
IKEv2 is done the first draft version says those new payloads are
marked as critical, but then the bit is removed after the draft
authors understand what critical bit means.

We do not currently have any extensions using critical payloads, so I
think we do not really need to care about them that much. I do not
also expect there to be critical payloads in future, as in most cases
we negotiate feature beforehand and after we have agreed that both
ends support feature X, we do not need to mark those payloads related
to feature X with critical flag, as we do know both ends support them.

Only time we would really need critical flag is when we would do
extension that would affect IKE_SA_INIT. Even it that case it might be
better to use new exchange like we did in session resumption.

> I am undecided on what is better, UNSUPPORTED_CRITICAL_PAYLOAD or

Unsupported critical payload cannot be used, as we do not have any
payloads we could point that we do not understand. All the payloads in
CREATE_CHILD_SA are already something the minimal client will
understand, and they are not marked as critical, so we cannot send
UNSUPPORTED_CRITICAL_PAYLOAD back. 

>     The minimal implementation of IKEv2 only uses first two exchanges

Fixed.

>     called IKE_SA_INIT and IKE_AUTH.  Those are used to create the IKE SA

Fixed.

> an empty INFORMATIONAL IKE Response message.

Section "2. Exchanges" already defines request and response as being
messages, there is no point of saying "request message" / "response
message". Also there is no need to talk about "CREATE_CHILD_SA IKE" or
"INFORMATIONAL IKE" request/response messages. The "CREATE_CHILD_SA
request" should be clear enough.

Rewrote the section to say:

      In addition to those messages minimal IKEv2 implementation need
      to understand the CREATE_CHILD_SA request enough to generate an
      CREATE_CHILD_SA response containing the NO_ADDITIONAL_SAS error
      notify. It needs to understand the INFORMATIONAL request enough
      to generate an empty INFORMATIONAL response to it.

> and only ever need to send out IKE Request messages for the IKE_SA_INIT

There is no other mimimal implementations that IKEv2 here, so I do not
think we need to explictly mention it. Also the oritinal text
explained that we need to send exactly one IKE_SA_INIT and one
IKE_AUTH, which your text omits. Changed the text say:

      Minimal implementation only need to support the role of
      initiator, so it does not ever need to send any other request as
      one IKE_SA_INIT, and one IKE_AUTH message.

> Message ID of the received IKE Request is used.

The last text abou tresponse messages is talked in the next paragraph,
and does not belong here, and I think my text about the message ids
for outgoing requests is clearer.

> or empty notification replies

Fixed.

> See my above added sentence that replaces this one.

But it was added to the wrong paragraph where it does not belong. 

> There isn't even "mapping" happening.

Yes, but full IKEv2 implementations do use mappings, and this is also
something that some implementors might need to change, i.e. instead of
supporting exactly one host, it can have several. Thats why the text
said "minimal implementations USUALLY has only one host".

> an SAr2 payload and with the selected Traffic Selectors.

Changed to:

      In the IKE_AUTH request, the initiator sends SA offer(s) in
      the SAi2 payload, and the proposed Traffic Selectors for the
      Child SA in the TSi and TSr payloads. The responder replies with
      the accepted offer in an SAr2 payload, and with the selected
      Traffic Selectors. 

>     In the wildcard case the server quite often narrow the range down

Fixed.

> accept the IP address pair or return an error.

Changed to:

      Using a single IP address pair as the Traffic Selectors when
      sending the IKE_AUTH request will simplify processing as the
      responder will either accept the IP address pair or return an
      error.

> will narrow the Traffic Selector range to range that is not acceptable

Changed.

> "by a minimal implementation" or "by minimal implementations"

I think the "by minimal implementations" is better. Changed to that.

> "minimal implementation" or "minimal implementations"

Changed to "minimal implementations".

> "a minimal implementation" or "minimal implementations"

I assume this is same as the one above.

> by a minimal implementation.

Fixed.

> that the initiator does not have any other IKE SAs between it and

Changed.

> those can be deleted by the responder.

Changed.

> requests, this will help the server to clean up leftover state.

Changed.

> recover from this scenario.

Changed.

> by sending back an empty INFORMATIONAL response.

Changed.

> Minimal implementations MUST be able

Changed.

> supporting CREATE_CHILD_SA, so you should stick to that here:

There has been text earlier too which explaines that usually minimal
implementations do this and that. Minimal implementations can support
whathever things they want to depending on the usage scenario where
they are used. 

> reply to those with a CREATE_CHILD_SA reply containing the NO_ADDITIONAL_SAS

We cannot add "MUST" here, as that would be against rfc7296. IKEv2 do
allow you to implement CREATE_CHILD_SA, and minimal implementations
are IKEv2 implementations, thus they can implement it.

I.e. minimal implementations MUST respond to the CREATE_CHILD_SA
request with CREATE_CHILD_SA response, but that response can contain
anything that is allowed by IKEv2, including error notification of
NO_ADDITIONAL_SAS, but also it can support CREATE_CHILD_SA and reply
with normal CREATE_CHILD_SA response. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Sep 2015 10:12:52 -0400 (EDT)

On Thu, 24 Sep 2015, Tero Kivinen wrote:

Thanks for the changes Tero. two topics left we haven't agreed on yet.

>      one IKE_SA_INIT, and one IKE_AUTH message.

I removed the counter of "1" because there could be retransmits and then
it sends more than one. How about:

       Minimal implementations only need to support the role of
       initiator, so it typically only sends an IKE_SA_INIT request
       which, when answered, is followed by an IKE_AUTH.

(if you reject this text, at least fix yours to use plural, eg minimal
implementations")

> said "minimal implementations USUALLY has only one host".

but minimal or not, one always uses the SPI as the lookup key for IKE
SAs and IPsec SAs. That's why I don't really understand why this remark
appears at all. But it isn't harmful, so I'm not against it.

>      the accepted offer in an SAr2 payload, and with the selected

Just change the first line to:

        In the IKE_AUTH request, the initiator sends the SA offer(s) in

> implementations do this and that.

Which i also did not like. You are trying to both define and not define
a minimal implementation.

> Minimal implementations can support

Sure, but you don't have to specify each variant between minimal and
full implementation. So you need to only say what the behaviour is of
the minimal client, and not extend it to describe behaviour of the
minimal implementation that also supports CREATE_CHILD_SA. We know what
clients do that support CREATE_CHILD_SA from RFC 7296. That's why my
suggested text tried to clarify the difference between not supporting
and exchange and supporting it well enough to say "not supported".

>> reply to those with a CREATE_CHILD_SA reply containing the NO_ADDITIONAL_SAS

We could find a middle ground using "Minimal implementations that
do not support CREATE_CHILD_SA requests MUST ...."

The point of the paragraph is to make clear that if you don't support
it, you should not return like INFORMATIONAL, you should still return
CREATE_CHILD_SA but with some specific payload. So implementors need
to write a CREATE_CHILD_SA stub. If they fully implement it, we don't
need to say anything.

> We cannot add "MUST" here, as that would be against rfc7296.

I don't see that. 7296 states:

 	An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE SA

and:

    The responder sends a NO_ADDITIONAL_SAS notification to indicate that
    a CREATE_CHILD_SA request is unacceptable because the responder is
    unwilling to accept any more Child SAs on this IKE SA.  This
    notification can also be used to reject IKE SA rekey.  Some minimal
    implementations may only accept a single Child SA setup in the
    context of an initial IKE exchange and reject any subsequent attempts
    to add more.

So I think it is clear from 7296 that if you do not implement
CREATE_CHILD_SA, that you must implement a stub CREATE_CHILD_SA
that still returns a valid CREATE_CHILD_SA exchange but only with
an error notification payload. You cannot respond with another
exchange, and you cannot respond with a fake CREATE_CHILD_SA that
for instance is not encrypted.

So to recap, why don't we:

 	Minimal implementations that do not support CREATE_CHILD_SA requests MUST  [...]

> IKEv2 do

In this definition, a full ikev2 implementation is a minimal
implementation too :P The point of the document is to describe the
situation where it deviates :P

> with normal CREATE_CHILD_SA response.

Yes, but that's out of scope of minimal clients. You whacked me about
minimal clients "single byte" importance, and then sneak in the entire
CREATE_CHILD_SA and multiple SA's :P

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 25 Sep 2015 13:10:22 +0300

> it sends more than one. How about:

Hmm.. I would have considered retransmissions of IKE_SA_INIT,
still being the one IKE_SA_INIT packet, ...

>        which, when answered, is followed by an IKE_AUTH.

But this text is ok for me too, so changed to this. 

> appears at all. But it isn't harmful, so I'm not against it.

It is there to explain to new users who do not know anything about the
IKEv2, that you do not use source IP to identify the IKE SA, you use
SPI. 

Fixed.

> do not support CREATE_CHILD_SA requests MUST ...."

I do not want to add such MUSTs which changes the RFC7296.

> to write a CREATE_CHILD_SA stub. If they fully implement it, we don't

The first sentence says that minimal implementation MUST be able to
reply to incoming CREATE_CHILD_SA reqeusts. This means you need to
send CREATE_CHILD_SA response back. The next question is, what is in
the response you send back. It could be normal CREATE_CHILD_SA
payloads, it could be error notify (either NO_ADDITIONAL_SAS, but
someone might use some other error code also). 

> for instance is not encrypted.

Yes, but if we make text here say that MUST send NO_ADDITIONAL_SAS,
then any implemenation following this document, is not allowed to
fully support CREATE_CHILD_SA.

Your original text said that if this document is supported, you do not
support CREATE_CHILD_SA and you MUST reply with NO_ADDITIONAL_SAS.
I do not agree on that statement. I think you can still be following
this document and implement CREATE_CHILD_SA.

> situation where it deviates :P

We are trying to tell what features of IKEv2 MAY be left out, we do
not specify what MUST be left out.

> CREATE_CHILD_SA and multiple SA's :P

What the minimal implemenations look like depends a lot from the
actual usage. I do not think they will be implementing
CREATE_CHILD_SA as it adds quite a lot of more code, for example after
that you do need to keep track of incoming and outgoing message IDs.
But on the other hand I do not want to add any normative text to say
that some features MUST NOT be implemented.

For example the other implementation we had did implement NAT-T,
mostly because he wanted to get the ESP packets inside the UDP
encapsulated packets over port 4500, and not mess up with privileged
port 500, and raw sockets. If the text would say NAT-T MUST NOT be
implemented, his implemented would not be following this spec...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Sep 2015 10:04:37 -0400 (EDT)

> I do not want to add such MUSTs which changes the RFC7296.

I don't think it does that, but I'm fine with whatever text you end up
using for this.

> fully support CREATE_CHILD_SA.

That is why my suggested text said "that do not implement
CREATE_CHILD_SA" - notice the "that".

> not specify what MUST be left out.

Yes, but I was trying to address the confusion of what it means if
something is "left out". If support for create_child_sa is left out,
does that mean you need to reply to such a request with that exchange
number, or use an informational exchange type. That is the confusion
I see developers could have. To me it seems even if you do not want
to support CREATE_CHILD_SA, you still need to implement answering a
CREATE_CHILD_SA with an error notify.

> actual usage.

And again, I disagree because this document defines what a minimal
implementation is. You yourself are talking about minimal
implementations that also might support CREATE_CHILD_SA. I guess
in a way you are describing "initiator only ikev2 clients" more than
"minimal". But anyway, as I said. I'm okay with your original text.

> implemented, his implemented would not be following this spec...

I was only trying to say that IF you do not support CREATE_CHILD_SA,
then you MUST still support enough of it to answer with a
CREATE_CHILD_SA stating an error code. That is different from say,
not supporting SESSION_RESUMPTION or Exchange Number 666.

Anyway, for the record. With the changes of me that you applied, I am
fine with the document moving forward. Thanks for your work on this.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Sep 2015 13:36:44 +0300

> CREATE_CHILD_SA with an error notify.

Yes.

And in the exchanges section there is text saying that:

      notify.

And this is expanded in the Other Exchanges section with text:

      Minimal implementations MUST be able to reply to incoming
      CREATE_CHILD_SA requests. Typical implementation will reject the
      CREATE_CHILD_SA exchanges by sending NO_ADDITIONAL_SAS error
      notify back:

I think tihs is clear enough.

> not supporting SESSION_RESUMPTION or Exchange Number 666.

I think the two sections I quoted above, do say that quite clearly. 

> fine with the document moving forward. Thanks for your work on this.

Ok, posting new version shortly which includes latest changes.
-- 
[email-masked]