ietf
[Top] [All Lists]

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

2015-09-24 05:58:10
Paul Wouters writes:
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).

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".

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?

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'

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

    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.

Yes. Removed.

    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?

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
NO_ADDITIONAL_SAS.

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 remainder are grammar/spelling nits:


    The minimal implementation of IKEv2 only uses first two exchanges

first -> the first

Fixed.

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

those -> these

Fixed.

    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.

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.

    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.

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.

    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.

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 notifications replies

or empty notification replies

Fixed.

    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.

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

    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.

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".



    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.

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

narrow -> narrows

Fixed.

    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.

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.

    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.

Changed.

    which can be ignored by minimal implementation.

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

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

    but any payload unknown to minimal implementation

"minimal implementation" or "minimal implementations"

Changed to "minimal implementations".

    notification payloads which can be ignored by minimal implementation.

"a minimal implementation" or "minimal implementations"

I assume this is same as the one above.

    that is quite commonly sent by the minimal implementation.

by a minimal implementation.

Fixed.

    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.

Changed.

    they can be deleted.

those can be deleted by the responder.

Changed.

    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.

Changed.

    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.

Changed.

    Minimal implementation MUST be

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

Changed.

    Minimal implementation also MUST be able

Minimal implementations MUST be able

Changed.

    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:

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. 

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.

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. 
-- 
kivinen(_at_)iki(_dot_)fi