Subject: [IPsec] IKEv2 TS payload

From: Toshihiko Tamura <[email-masked]>
Date: Tue, 22 Apr 2008 16:04:20 +0900

Hello,

I'm one of the members of TAHI project.
There's one unclear point about IKEv2 Traffic Selector payload.

We use TS payload, TSi and TSr, for setting IPsec selectors.
But I'm afraid that the definition of "i" and "r" is so ambiguous.
Of course, it's perfectly clear in the case of initial exchange.
But in the case of rekeying, there is a possibility that
it becomes problem.

(Initiator)  (Responder)
     |           |
     |---------->| IKE SA INIT
     |<----------| IKE SA INIT
     |---------->| IKE AUTH
     |  (snip)   | 
     |<----------| IKE AUTH 
     |           | (Initial Exchange completed)
     |           | 
     |           | 
     |<----------| Create Child SA request
     |           |     (HDR, SAi1, Ni, TSi, TSr, ...)
     |           |
     |---------->| Create Child SA response
     |           |     (HDR, SAi2, Nr, TSi, TSr, ...)
     |           |
     V           V

In above case, a responder at initial exchange initiates rekey.
Which is correct, #1 or #2?

TSi in Create Child SA message includes the address and 
port number for
   #1: the initiator which has established initial SAs.
   #2: the initiator which initiates rekeying.

Vice versa for TSr.

Best Regards,
-----
Toshihiko TAMURA, NTT
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Apr 2008 10:57:27 +0300

#2 - the initiator that initiates rekeying.

This is explained in section 2.9 of RFC 4306

    The first of the two TS payloads is known as TSi (Traffic Selector-
    initiator).  The second is known as TSr (Traffic Selector- 
responder).
    TSi specifies the source address of traffic forwarded from (or the
    destination address of traffic forwarded to) the initiator of the
    CHILD_SA pair.

Yoav

On Apr 22, 2008, at 10:04 AM, Toshihiko Tamura wrote:

> Scanned by Check Point Total Security Gateway.
>

---

From: Toshihiko Tamura <[email-masked]>
Date: Tue, 22 Apr 2008 17:50:28 +0900

Thanks Yoav,

> CHILD_SA pair.                               ^^^^^^^^^^^^^^

So you mean,
the word "the initiator" in above sentence means the initiator
which initiate rekeying. I also agree to that.

But there is a possibility to interpret the meaning of "the initiator"
as the initiator which has established initial SAs.
(I can say "original initiator"?)

Actually I know some IKEv2 supported equipments
which implement with not only #2 but #1.
I would just like to point out it may be ambiguous.
Am I being worried too much?

Best regards,
Toshihiko Tamura

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Apr 2008 16:21:04 +0300

> (I can say "original initiator"?)

The 1.3 section is quite clear about this:

1.3.  The CREATE_CHILD_SA Exchange
...
   Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
   section the term "initiator" refers to the endpoint initiating this
   exchange.
...

In cases where original IKE initiator is meant the term "original IKE
initiator" or "original initiator of IKE_SA" is used (like in section
2.2, 2.6, 2.14 etc).

One thing you might also note, that the values of the Traffic selector
payloads sent in the rekey does NOT need to match the values used in
the current SA which is being rekeyed. Preferrably they should be from
the decorrelated policy entry which caused the original SA to be
created, i.e. before narrowing happened in the original exchange. Of
course the responder should narrow them down to selection that
includes the original SAs traffic.

Different implementations do different things there, and regardless
what they do both ends should interoperate (i.e. even if initiator of
the rekey selects the same traffic selectors that is currently in the
SA, that should work, and if initiator of the rekey uses wider traffic
selectors specified in its policy (which include the old traffic
selectors), the responder of the rekey can either use new wider set of
traffic selectors, or narrow them down to original set.

Note, that both ends can even narrow it down to more than the original
set included, which will cause new SA(s) to be created for those
traffic that was excluded from the old SA (this might happen when the
policy of the one end has changed, for example some parts of the
original traffic selectors are not allowed after the policy change). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec