Subject: [IPsec] IKEv2bis, comments about sections 1-2

From: <[email-masked]>
Date: Mon, 18 Jan 2010 17:47:31 +0100

I'm doing a yet another full review pass over the whole document (not
just diff as I've usually done; to find issues/inconsistencies that
diffs wouldn't necessarily show). So far, I've covered Sections 1 
and 2.

Substantial comments:

- Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
of the WG draft) allows sending INVALID_IKE_SPI notification inside an
existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
sure if it really brings any benefits?

- Section 2.8.1, NO_PROPOSAL_CHOSEN near the end. This is probably
left over from old versions, and should be something else now
to align with Section 2.25?  

- Section 2.8.2: (already covered by issue #135)

- Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
Nr are used in the calculation". This section has two calculations
involving Ni/Nr, but this sentence should only apply to the former.
Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED
(but all bits are used when calculating SK_*)"

- Section 2.17: See
http://www.ietf.org/mail-archive/web/ipsec/current/msg04673.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04681.html

- Section 2.23, last bullet: "MUST NOT be used when MOBIKE is used"
This is actually not exactly what Section 3.8 of [MOBIKE] says (it
does allow using this for ESP).  I would suggest just referring to
Section 3.8 of [MOBIKE] for details.

- Section 2.23.1: If the responder doesn't find SPD entry for
transport mode with the modified traffic selectors, and does a lookup
with the original selectors, if it finds an entry for transport mode,
can it use it? (And would that screw up the initiator processing of
the reply? Unfortunately,this question is relevant for RFC 5555...)

- Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA": Is this really
necessary? I think this notification should only occur in cases where
DELETE payload for this Child SA pair has already been sent, and
probably has been processed already by the time the CHILD_SA_NOT_FOUND
notification is received. 

- Section 2.25.2, "If a peer receives a request to delete a Child SA
when it is currently rekeying the IKE SA, it SHOULD reply as usual,
with a Delete payload." I noticed this is different from what RFC 4718
recommended, but this is probably OK, given the other text...  (but I
still hope this was intentional change :-)

Somewhat substantial:

- Section 1.3.1: delete sentence "When an IKE SA is not created..."
(this section is about CREATE_CHILD_SA, and the IKE_AUTH error
messages are already well described in Section 1.2).

- Section 1.5 doesn't read well, and needs a rewrite. I can
provide text once the substantial issue re: INVALID_IKE_SPI
is decided.

- Section 2.6, paragraph beginning with "In addition to cookies..",
and Section 2.7, last paragraph, are both in very strange places (and
basically say the same thing). Suggest combining both, and adding them
to the end of paragraph "In the first message.." in 2.6:

   "When the exchange does not result in the creation of an IKE SA on
   the responder (due to, for example, COOKIE, INVALID_KE_PAYLOAD, or
   NO_PROPOSAL_CHOSEN), the responder's SPI will be zero also in the
   response message. However, if the responder does send a non-zero
   responder SPI, the initiator should not reject the response for
   only that reason."

- There are two places that have very similar text about
INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and
Section 2.7 (for IKE_SA_INIT exchange).  Especially the latter seems a
bit strange, everything else in that section applies to
CREATE_CHILD_SA exchanges, too, but this paragraph explicitly applies
to IKE_SA_INIT only (although INVALID_KE_PAYLOAD works roughly the
same way in CREATE_CHILD_SA, too). Perhaps the text in 2.7 should be
moved to 1.2?

- Section 2.8, sentence: "Note that, when rekeying..." This is in
wrong place; the rest of this paragraph is about IKE_SA rekeying, so
it should be moved to the previous paragraph.

- Section 2.18, last paragraph: suggest adding "PRF" to the list of
things that come from the new exchange.

- Section 2.23, paragraph starting: "An initiator can float..."  needs
some clarifications. Probably "UDP encapsulation/encapsulated" should
be "UDP encapsulation of ESP/UDP-encapsulated ESP" (since at other
places, the document also talks about IKE packets being UDP
encapsulated).

- Section 2.23.1: I would strongly suggest using the word "original
address" (just like RFC 3947) instead "real address" (since both
addresses are very real).

- Section 2.23.1, "- Store the original traffic selectors.."  (occurs
twice) I would suggest using "received" instead of "original" here.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 11:24:49 +0200

> sure if it really brings any benefits?

There is no way to send INVALID_IKE_SPI inside IKE SA, as the section
3.10 says that the IKE SPI is never sent inside the notification
payload (For a notification concerning the IKE SA, the SPI Size MUST
be zero and the field must be empty.) and the IKE SPI is taken from
the packet. Sending INVALID_IKE_SPI inside IKE SA would mean that the
IKE SA you are sending the packet inside is invalid...

The section 2.21.4 is very clear that INVALID_IKE_SPI MUST NOT be
cryptographically protected, i.e. it is sent outside the IKE SA.

I think the 1st paragraph is quite wrong and the

  If the receiving node has an active IKE SA to the IP address from
  whence the packet came, it MAY send a notification of the wayward
  packet over that IKE SA in an INFORMATIONAL exchange.

part should be removed.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 13:12:11 +0200

[email-masked] writes:
> can it use it? 

I do not think it can use the transport mode SA using original
selectors. This of course depends which traffic selectors are used
when installing the SA data to SAD. If those original selectors are
used then incoming packets will be dropped because they do not match
the selectors for the SA (RFC4301 section 5.2, step 5).

If modified selectors is used when installing SA then those selectors
were not matched against the SPD, and this can cause spoofing attacks.

> (And would that screw up the initiator processing of
> the reply?

That again depends which traffic selectors are returned. If original
traffic selectors are returned then initiator do not get information
about the original addresses, thus it cannot do incremental checksum
updating. Also depending what kind of checks initiator does, it might
cause initiator to fail the reply processing.

> Unfortunately,this question is relevant for RFC 5555...)

What kind of things does the RFC5555 require?
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 13:20:21 +0200

> notification is received.

I agree on that, and I proposed new wording for that:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist A peer that receives
   a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA
   (if it still exists, as most likely delete notification sent by the
   other hand has already deleted it) and send a request to create a new
   Child SA from scratch if such Child SA does not yet exists.

> still hope this was intentional change :-)

This was intentional change.

When we discussed this in the design team, nobody see any reason why
it should reply without the delete payload. In all implementation I
know the SPI itself is enough to delete the SA, it does not really
matter whether that Child SA was already moved to the new IKE SA or
whether it was still in the Old IKE SA. This means sending delete to
either one of the SA will cause the Child SA to go and that SPI cannot
refer to any other Child SA.

So most of the implementations will be replying with delete payload as
usual and the Child SA is deleted. Implementations are always allowed
not to return the delete payload immediately if they like, so the old
behavior from RFC4718 is still also allowed, but not preferred.

We tought it would be best to try to limit the amount of cases where
half-closed SAs could be created so we though it is better to close
the Child SA directly without going first to the half-closed state,
and waiting for the other end to send another delete payload (using
new IKE SA?) for the other half.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 12:27:40 +0100

Tero,

I agree with your analysis (I hadn't noticed that this 
doesn't even work).

Best regards,
Pasi

> -----Original Message-----
> From: ext Tero Kivinen [mailto:[email-masked]]
> Sent: 19 January, 2010 11:25
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: INVALID_IKE_SPI inside IKE SA (was: [IPsec] IKEv2bis, comments
> about sections 1-2)
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 14:41:17 -0800

>  packet over that IKE SA in an INFORMATIONAL exchange.

Done.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 11:38:45 +0100

> the selectors for the SA (RFC4301 section 5.2, step 5).

Actually, the incoming packets could actually match the selectors if
they somehow take a different "route" than the IKEv2 packets, and
bypass the NAT.

(This is what's happening in RFC5555; see below)

> were not matched against the SPD, and this can cause spoofing attacks.

I agree this would violate the policy.

> What kind of things does the RFC5555 require?

Basically, it's assuming that even if you're running IKEv2 over IPv4
(and that IPv4 address is NATted), you can still negotiate transport
mode SAs for IPv6 addresses (which won't get NATted).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 11:41:26 +0100

Tero Kivinen wrote:
>    A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer
>    receives a request to rekey a Child SA that does not exist A peer
>    that receives a CHILD_SA_NOT_FOUND notification SHOULD silently
>    delete the Child SA (if it still exists, as most likely delete
>    notification sent by the other hand has already deleted it) and
>    send a request to create a new Child SA from scratch if such
>    Child SA does not yet exists.

Thanks -- this is much clearer.

> > - Section 2.25.2, "If a peer receives a request to delete a Child
> > SA when it is currently rekeying the IKE SA, it SHOULD reply as
> > usual, with a Delete payload." I noticed this is different from
> > what RFC 4718 recommended, but this is probably OK, given the
> > other text...  (but I still hope this was intentional change :-)
> 
<snip>

OK; with this reply, I'm OK with closing issue #142.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2010 14:14:35 +0200

> mode SAs for IPv6 addresses (which won't get NATted).

Hmm.... Let me see. They have IKEv2 session running over IPv4
addresses, and then they try to create IPsec SA using IPv6 addresses
using transport mode over that IKEv2 SA. How are they going to do it,
as section 2.11 says:

----------------------------------------------------------------------
2.11.  Address and Port Agility

   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over.
----------------------------------------------------------------------

which usually means that for transport mode the addresses you expect
to se on ESP packets are same as what they were for the IKE packet
too, which is impossible now as the IKEv2 runs over IPv4, but ESP
packets run over IPv6.

Also even if they use packet where src = IP1 (ipv4), and dst = IPN2
(ipv4) and then it is natted twice to src = IPN1 (ipv4) and dst = IP2
(ipv4) (using the picture in section 2.23.1), with traffic selectors:

   TSi = any, any, src-IPv6-address - src-IPv6-address
   TSr = any, any, dst-IPv6-address - dst-IPv6-address

and try to negotiate transport mode using those traffic selectors, I
think most of the implementations will not allow such SA to be
created.

As there is no NAT for the IPv6 addresses, then the SPD lookup based
on the traffic selectors would be fine, but there is no way to know
whether there is NAT between the IPv6 address or not, as we only
tested the presense of NAT for IPv4 addresses.

I think the only easy solution to that kind of problem is to run two
IKEv2 SAs between the peer, one for IPv4 traffic using NAT'ed IPv4
addresses, and another using IPv6 addresses and IPv6 transport mode
traffic.

It seems the RFC5555 is trying to break the section 2.11 rule, and
thinks IKE can be used in such way to create SAs between any
IP-addresses instead between the address over which the IKE SA runs
on.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 12:30:55 +0100

> using transport mode over that IKEv2 SA. How are they going to do it,

Hmm... What exactly that text means is actually a good question.  
If you have a multi-homed host using SCTP, for example, it would make
sense to create a transport mode SA whose traffic selectors include
more than one IP address. If there are no NATs, this would work fine
(even though only one of the addresses in TS payloads would be equal
to the address used for sending the IKE packet).

So I'm not so sure if this text really prohibits the situation where
transport mode traffic selectors aren't exactly the same as the
addresses used for sending the IKE packet...
 
> think most of the implementations will not allow such SA to be

Well, this is not the only place where RFC5555 may not work with just
any IPsec implementation, and can require MIP-specific tweaks... 
(search for "implementation" in Section 5 if you really want to know)
 
> tested the presense of NAT for IPv4 addresses.

Yes, that's true. (And even if you know there's NAT, you would not know
what the mapped addresses are.)
 
> IP-addresses instead between the address over which the IKE SA runs

Personally, I've come to the conclusion that the IPsec text in RFC
5555 was a big mistake (and I share some blame for much of that 
text -- at the time it was written, I still thought it was just ugly, 
but would work)...

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Jan 2010 14:18:29 +0200

> addresses used for sending the IKE packet...

I agree that it does not explictly forbid having multiple addresses in
transport mode SA, but I do not think it is possible.

If we think this setup from the initiator point of view. He is sending
packet from src1 to dst1. The packet will trigger IPsec negotiation
which will then do SPD lookup. If entry is found from there, and this
is transport mode then the SPD does not have local and remote tunnel
addresses, but instead it assumes that src1 and dst1 are the address
used when creating IKE (or selecting IKE).

How do you plan to create such things using RFC4301 architecture?

I do not think SPD have any other places to store that kind of
information than in the local/remote tunnel addresses, and those are
only used in tunnel mode:

                - (if tunnel mode) local tunnel address -- For a
                  non-mobile host, if there is just one interface, this
                  is straightforward; if there are multiple
                  interfaces, this must be statically configured.  For a
                  mobile host, the specification of the local address
                  is handled externally to IPsec.
                - (if tunnel mode) remote tunnel address -- There is no
                  standard way to determine this.  See 4.5.3, "Locating
                  a Security Gateway".

Hmm.. it might be possible that if the PAD entry linked with that
transport mode SPD contains "peer gateway information" field which
indicates the security gateway, but the RFC4301 also says that:

   For example, assume that IKE A receives an outbound packet destined
   for IP address X, a host served by a security gateway.  RFC 2401
   [RFC2401] and this document do not specify how A determines the
   address of the IKE peer serving X.

which would indicate that it might be possible to do this kind of
things with RFC4301 architecture. On the other hand it is talking
about security gateway, which usually indicates tunnel mode, as
security gateway is defined to be:

	 A security gateway is an intermediate system implementing
   IPsec, e.g., a firewall or router that has been IPsec-enabled.

> (search for "implementation" in Section 5 if you really want to know)

I think knowledge adds pain, so I rather not... every time I try read
those MIP specific tweaks my heads start hurting, and I feel that
those tweaks are not going to work ever with any real IPsec
implementation.

> what the mapped addresses are.)

Yes.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 13:30:07 +0100

Hi Tero,

RFC 4555 Appendix A.2 has more text discussing this topic (when you
need to create a new ESP/AH SA, how do you know where to send the IKE
packets). It basically concluded this is beyond the scope of the spec,
and could be very simple (e.g. just configure a single IP address
somewhere), or quite complex (e.g. multiple gateways to select from).

So I think this is quite possible with RFC 4301 architecture...
(but probably not supported by all implementations)

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Tero Kivinen
> Sent: 28 January, 2010 14:18
> Subject: Re: [IPsec] RFC5555 and Section 2.23.1 (was: IKEv2bis,
> comments about sections 1-2)
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec