>        If a CREATE_CHILD_SA exchange includes a KEi payload, at
>        least one of the SA offers MUST include the Diffie-Hellman
>        group of the KEi MUST be an element of the group the
>        initiator expects the responder to accept (additional
>        Diffie-Hellman groups can be proposed).

I think the above sentece is missing some things: "... include the
Diffie-Hellman group of the KEi MUST be an ..."

Perhaps it should be:

"If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi. The
Diffie-Hellman group of the KEi MUST be an element of the group the
initiator expects the responder to accept (additional Diffie-Hellman
groups can be proposed)."

Also if we think more about the IKE SA rekeying, I do not think there
is any reason to do that unless you also do new Diffie-Hellman there
too. Rekeying IKE SA because of the IKE message ID wrapping is not
common. The current IKEv2 text is not clear wheather the intension was
that IKE SA rekey MUST have KE payloads, but I think we should mandate
them, i.e. say in the NEW-1.3.2 that KE payloads are not optional
there.

The section 5 should also point out that INTERNAL_ADDRESS_EXPIRY is
not mandatory in the IKEv2, and in most cases it would be best not to
use it at all. Most of the clients will not tolerate the server not to
give the same address back when the address lease expires. This means
that only reason to do address expiry is to know when the client stops
using the address. In IKEv2 this time is very clear as it is also tied
to the IKE SA. If the IKE SA is deleted then the client cannot use the
address anymore, and when he recretes the IKE SA he need to get the
address again using configuration payloads (he also need to recreate
all IPsec SAs and change the traffic selectors to match new addresses
etc).

Because of that I would recommend that INTERNAL_ADDRESS_EXPIRY SHOULD
NOT be used in the IKEv2.  

> 6.1  Diffie-Hellman for first CHILD_SA
> 
>   Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
>   Ni/Nr payloads.  This implies that the SA payload in IKE_AUTH
>   exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
>   any other value than NONE.

And most commonly that should be coded as leaving out transform type 4
completely.

> 6.5  Reducing the window size
> 
>   In IKEv2, the window size is assumed to be a (possibly configurable)
>   property of a particular implementation, and is not related to
>   congestion control (unlike the window size in TCP, for instance).
>
>   In particular, there is no way to reduce the window size of an
>   existing IKE_SA.  However, when rekeying an IKE_SA, the new IKE_SA
>   starts with window size 1 until it is explicitly increased by sending
>   a new SET_WINDOW_SIZE notification.

More precisely, you could send SET_WINDOW_SIZE notification with
smaller window than before, but it is not defined what responder
should do in that case. He might have more request than allowed by the
new window size already out, thus he cannot reduce the window size.
Because of this the reduction of window size cannot be done before the
responder processing rules have been define, i.e. currently reducing
window size is forbidden.

> 6.9  SPI values for messages outside of an IKE_SA
>
>   The IKEv2 specification does not say what SPI values should be used
>   for Informational requests sent outside of an IKE_SA.
>
>   There seem to be two cases when such a message can be sent:
>   INVALID_IKE_SPI and INVALID_SPI notifications.  Especially in the
>   latter case, no meaningful IKE SPI values are available.
>
>   A strict interpretation of the specification would require the sender
>   to invent garbage values for the SPI fields.  However, we think this
>   was not the intention, and using zero values is acceptable.

I think whole section should be clarified. There cannot be any
informational exchanges outside the IKE SA, thus there will always be
IKE SPIs for that packet. IKEv2 DOES NOT have non-authenticated
notifications that the IKEv1 had.

The section 1.5 describes about case where the responder of packet
could send out packet looking like informational exchange as a
response to the packet it receives, but that is not part of an
informational exchange, and responder should not act based on the
received packet, except it might start DPD because of the packet (i.e.
it is treader similarly than ICMP host unreachable etc are treated).

In that case using all zero SPI fields is acceptable.

> 6.11  INVALID_IKE_SPI
...
>   Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA,
>   and it is not about an existing SA, it seems that using Notification
>   Data would be the logical choice.  However, this issue needs more
>   discussion and we do not yet propose any solution in this document.

The INVALID_IKE_SPI can also be sent inside the existing IKE SA. See
section 1.5 of IKEv2 draft for more details.

As the description of the INVALID_IKE_SPI says that unrecognized
destination SPI, which would indicate that destination SPI was the one
we didn't know anything about. So my interpretation would be to use
SPI field of the notification payload (as it does not say put it in
the data field), and only put destination SPI there, with protocol ID
of IKE. On the other hand section 3.10 says sthat SPI size for the
notification concerning MUST be zero, so I agree this is not really
consistent. 

> 6.12  Which message should contain INITIAL_CONTACT
...
>   The text does talk about authenticated identities, so it seems the
>   notification cannot be sent before both endpoints have been
>   authenticated.  Thus, the possible places are the last IKE_AUTH
>   response message and a separate Informational exchange.

Initiator usually knows to whom is is supposed to talk to and he knows
weather he has SA with him before or not (if he had IKE SA he would
have used it, or he had some other reason not to use it).

So it means that initiator can send INITIAL_CONTACT in IKE_AUTH and
responder can respond to that in the same packet. I would actually
prefer that instead of using separate informational exchange.

>   Based on how this was implemented in IKEv1, it seems the intent was
>   to use a separate Informational exchange.

In IKEv1 it was supposed to be sent inside the main mode, but as the
extra payloads are not authenticated there, some implementations use
separate informational exchange for it. For IKEv1 it was actually very
bad idea to use separate informational exchange as they were not
reliable.

>   o  The message IDs of IKE_SA_INIT messages is unclear if there are
>      cookies followed by INVALID_KE_PAYLOAD.  See "Question about
>      N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004.
>      This definitely needs to be clarified.

I do not think this is unclear. When you create state in the responder
you allocate IKE SPI and start using message IDs. If you return
N(COOKIE), you do not allocate anything, thus you do not allocate IKE
SA SPI, and as message ID is property of IKE SA, you do not use it
yet.

If you return N(INVALID_KE_PAYLOAD) that is fatal error, and again you
do not need to allocate IKE SA nor the SPI, thus no message ID can be
stored. When the initiator retries with both N(COOKIE) and
with proper group, then you finally allocate IKE SA and the SPI, and
start using message IDs.

Thus message id of IKE_SA_INIT should always be zero.
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec