Subject: [IPsec] Re IKEv2 - INVALID_IKE_SPI/INVALID_SPI & Protocol ID

From: Jeffrey Sun <[email-masked]>
Date: Wed, 17 Oct 2007 10:23:18 -0700

Hi Everyone,
  Found some minor issues that I thought I'd bring up.

A.  INVALID_IKE_SPI & INVALID_SPI (RFC4718-Section 7.7)
If Bob receives an IKE request message with unknown SPIs, he MAY send an 
one-way INFORMATIONAL request message containing a N(INVALID_IKE_SPI) 
Payload to Alice.  Regarding the IKE Header, Bob copies the IKE SPIs and 
Message IDs from the IKE request message with unknown SPIs.  What about 
the Flags Field?  Safe to assume he should fill out the Version Flag 
according to his specifications, set the Response Bit to ZERO, and 
invert the Initiator Bit based on what he received in the IKE request 
message with unknown SPIs?

This leads to the case of INVALID_SPI (i.e. ESP or AH Packet)...in an 
analogous scenario, their is no previous Message ID to copy or Flags 
Field to parse.  I assume then, like the IKE SPIs, the Message ID set to 
ZERO and the Flags Field's Initiator Bit be set to ZERO.  Thus, in the 
context of an one-way INFORMATIONAL request message with a 
N(INVALID_SPI) Payload, the Flags Field's Initiator Bit should 
essentially be ignored.

B.  Protocol ID (RFC4718-Section 7.8)
Section 7.8 calls out the N(REKEY_SA) Payload and the 
N(INVALID_SELECTORS) Payload as the only two payloads that require a 
NON-ZERO Protocol ID assignment.  I would think that the N(INVALID_SPI) 
Payload would also be included requiring a NON-ZERO Protocol ID 
assignment (i.e. AH or ESP).

Thanks in advance for the help.  If I totally overlooked something, my 
apologies.

- Jeff Sun

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: ns srinivasa murthy <[email-masked]>
Date: Thu, 18 Oct 2007 13:34:46 +0530

At 10:53 PM 10/17/2007, Jeffrey Sun wrote:
>If Bob receives an IKE request message with unknown SPIs, he MAY 
>send an one-way INFORMATIONAL request message containing a 
>N(INVALID_IKE_SPI) Payload to Alice.  Regarding the IKE Header, Bob 
>copies the IKE SPIs and Message IDs from the IKE request message 
>with unknown SPIs.  What about the Flags Field?  Safe to assume he 
>should fill out the Version Flag according to his specifications, 
>set the Response Bit to ZERO, and invert the Initiator Bit based on 
>what he received in the IKE request message with unknown SPIs?

Flags shall read R(Response bit) = 0,V(version Number) = Better to 
keep whatever is received in the request so that requestor wont drop 
our response due to difference in version numbers.I(Initiator bit) = 
I think it is better to copy this bit from request (as we did not 
send any responder messages previously with these SPIs before).These 
messages are only to be audited and Admin can make some inferences.

>This leads to the case of INVALID_SPI (i.e. ESP or AH Packet)...in 
>an analogous scenario, their is no previous Message ID to copy or 
>Flags Field to parse.  I assume then, like the IKE SPIs, the Message 
>ID set to ZERO and the Flags Field's Initiator Bit be set to 
>ZERO.  Thus, in the context of an one-way INFORMATIONAL request 
>message with a N(INVALID_SPI) Payload, the Flags Field's Initiator 
>Bit should essentially be ignored.

Message ID must be copied from the request packet as we are sending a 
response.While sending the response ,copy the Initiator bit from the 
request as we never responded before using this SPI.

>NON-ZERO Protocol ID assignment.  I would think that the 
>N(INVALID_SPI) Payload would also be included requiring a NON-ZERO 
>Protocol ID assignment (i.e. AH or ESP).

We shall copy Protocol ID value from request as we want to convey 
that "this SPI is invalid for this protocol".

>Thanks in advance for the help.  If I totally overlooked something, 
>my apologies.
>
>- Jeff Sun
>
>

********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.
 
Intoto Inc.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Oct 2007 12:14:05 +0300

> message with unknown SPIs?

Yes.

For the version number field, he should have already been
processing that before getting this far, i.e. he must be able to talk
with the version the other end is trying to send otherwise he would be
sending INVALID_MAJOR_VERSION notify back. So as he can talk with the
version other end sent, he should fill in the version number using
regular rules, i.e. copy it from the request, but set the version flag
in case he can talk higher version also. 

> N(INVALID_SPI) Payload, the Flags Field's Initiator Bit should 

If there is IKEv2 SA with the host where you are sending INVALID_SPI
notify, then you simply send it as normal informational message, i.e.
fill in the SPIs, next message ID, flags as you would for normal IKEv2
informational exchange, and you get ACK back like normally.

In the case there is NO IKEv2 SA with the host you want to send the
INFORMATIONAL INVALID_SPI notify, then you will create temporary IKEv2
SA and use that, i.e. you are initiator for the message. You can if
you like fill in the initiator SPI, but you can also use zeroes
(RFC4718 section 7.7. last paragraph). You are initiator, so you set
the Initiator flag, you fill in the major and minor versions as
specified in your policy, and as this is not response, you clear the
response flag. Message ID should be 0, as this is first message sent
on that direction with that "temporary" IKEv2 SA.

> assignment (i.e. AH or ESP).

RFC4306 says that the SPI of the invalid packet is stored in the
Notification Data field, not in the SPI field of the notify payload.
Because of this, the SPI field of the notification data is empty, thus
there is no protocolID associated to it (from RFC4306):

        INVALID_SPI                              11

            MAY be sent in an IKE INFORMATIONAL exchange when a node
            receives an ESP or AH packet with an invalid SPI.  The
            Notification Data contains the SPI of the invalid packet.
	    ^^^^^^^^^^^^^^^^^
            This usually indicates a node has rebooted and forgotten an
            SA.  If this Informational Message is sent outside the
            context of an IKE_SA, it should be used by the recipient
            only as a "hint" that something might be wrong (because it
            could easily be forged).
-- 
[email-masked]

---

From: Jeffrey Sun <[email-masked]>
Date: Thu, 18 Oct 2007 10:28:39 -0700

> on that direction with that "temporary" IKEv2 SA.
RFC4306, Section 1.5 states:

...
If it does not have such an IKE_SA, it MAY send an Informational message
without cryptographic protection to the source IP address.  Such a
message is not part of an informational exchange, and the receiving
node MUST NOT respond to it.  Doing so could cause a message loop.

RFC 4718, Section 7.7 states:

The IKEv2 specification is not quite clear what SPI values should be
used in the IKE header for the small number of notifications that are
allowed to be sent outside an IKE_SA.  Note that such notifications
are explicitly not Informational exchanges; Section 1.5 makes it
clear that these are one-way messages that must not be responded to.

There are two cases when such a one-way notification can be sent:
INVALID_IKE_SPI and INVALID_SPI.

Tero:
Based on these two statements, I've always assumed that only two one-way 
INFORMATIONAL messages (without cryptographic protection) were allowed: 
INVALID_IKE_SPI and INVALID_SPI. From what I've read, I've don't recall 
coming across the utilization of a "temporary" IKEv2 SA to transmit the 
N(INVALID_SPI) Payload and as a result, I've always considered that the 
processing of the INVALID_IKE_SPI and the INVALID_SPI were similar.

Namely, the following would occur:
1. Bob crashes and receives a wayward ESP packet from Alice.
2. Bob sends out an unprotected one-way INFORMATIONAL request message 
containing the N(INVALID_SPI) Payload. The Notification Data contains 
the ESP SPI (as you've clarified, thanks for that).
3. Alice gets that message and attempts to find the IKE_SA associated 
with that Source Address and ESP SPI.
4. If Alice finds such IKE_SA, she does the liveliness checks (i.e. 
empty INFORMATIONAL exchanges)
etc, etc.

Of course, Alice should rate limit the number of actions triggered by 
the receipt of an N(INVALID_SPI). Thanks for the other clarifications.
- Jeff Sun

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Oct 2007 15:13:43 +0300

> INFORMATIONAL messages (without cryptographic protection) were allowed: 

Yes. That is correct.

> processing of the INVALID_IKE_SPI and the INVALID_SPI were similar.

NOte, te "temporary" IKEv2 SA only exists for sending that ONE packet
without cryptographic protection and it is destroyed immediately when
the packet has been sent to the network (or even before it is sent to
network, just after it is given to the operating system).

But for example in some implementations you do need to have IKEv2 SA
context structures, so you can send IKEv2 packets out, so what you may
do in that case, is to internally allocate temporary IKEv2 SA context,
initialize it with some data, use that to generate the correctly
formatted notify packet, give that packet to operating system to be
delivered, and then immediately free the IKEv2 SA context you
allocated. So the IKEv2 SA context is only allocated for few
milliseconds, which makes it very temporary. But because of this you
may for example need to allocate proper initiator SPI for it (and use
zeros for the responder SPI, and use it when sending the packet out.

Another option is to just format the notify packet without that kind
of fake temporary IKEv2 SA, and send it out with just zeroes in the
initiator and responder SPI fields.

That means that in the responder end you should be able to process
notify packets either having the initiator SPI filled in or filled
with zeros.

> empty INFORMATIONAL exchanges)

Yes, that is one case.

-- 
[email-masked]