Subject: [Ipsec] questions about the traffic selector in IKEv2

From: "fan zhao" <[email-masked]>
Date: Thu, 14 Jun 2007 02:17:40 +0100

Hi,

I have a question about the traffic selector in IKEv2.
There are traffic selector fields, TSi and TSr in IKE_AUTH
and CREATE_CHILD_SA message from the initiator.

What is the relationship between the traffic selector fields in
these different messages? In other words, TSi in IKE_AUTH
is as same as TSi in CREATE_CHILD_SA or different or
one is the subset of the other?

Thank you very much.

Sincerely,
fan

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

---

From: "DIPANJAN DATTA" <[email-masked]>
Date: 15 Jun 2007 06:25:54 -0000

Hi Fan,
See my replies below. If the other members of the mailing list don't agree with my explanations, please correct me.

Regards
Dipanjan 

On Thu, 14 Jun 2007 fan zhao wrote :
>Hi Dipanjan,
>
>Thanks for your help.
>Please see my reply in line.
>
>
>On 14 Jun 2007 05:37:08 -0000, DIPANJAN DATTA <
>[email-masked]> wrote:
>>
>>Hi,
>>TSi & TSr fields are applicable only when CHILD SAs are being created.
>>CREATE_CHILD_SA is used to create subsequent CHILD SAs after the IKE SA is
>>established. Hence the presence of TSi & TSr fields in a CREATE_CHILD_SA is
>>self-explanatory and also this set of TSi & Tsr values are relevant only for
>>this CHILD SA which is being created.
>>
>
>OK.
>
>Now in IKE_AUTH exchange, the previous IKE_SA_INIT exchange is
>>authenticated an hence the creation of the IKE SA , which was started in the
>>IKE_SA_INIT exchange, is completed. Also during the IKE_AUTH exchange,
>>creation of the first CHILD SA is piggybacked along with this creation of
>>IKE SA.
>>
>
>OK. I see. Is creating a CHILD SA in the IKE_AUTH exchange optional? It
>seems not, right?

Reply: It is not optional. It is mandatory. This is one of the major differences between IKEv1 & IKEv2. In IKEv1, it would require exchange of at least 9 messages (6 in Main Mode + 3 in Quick Mode) before the first CHILD SA is created, but in IKEv2 the first CHILD SA is in place just after 4 messages (2 in IKE_INIT_SA + 2 in IKE_AUTH).
>
>Also, SAi1 and SAr1 in the IKE_SA_INIT are used to protect the following
>message exchange
>in the IKE_AUTH and the CREATE_CHILD_SA and they have nothing related with
>SAi2 offer in the IKE_AUTH exchange and SA in the CREATE_CHILD_SA.
>Do I understand correctly?

Reply: You are correct. The SAi1 & SAr1 in IKE_SA_INIT exchange are meant to negotiate parameters for creating only the IKE SA (and not any CHILD SA), which in turn is subsequently used to protect the further exchanges like IKE_AUTH, CREATE_CHILD_SA or INFORMATIONAL Exchanges.
>
>The TSi & TSr values present in the IKE_AUTH messages are meant for the
>>creation of that particular CHILD SA and has no relation to the IKE SA being
>>created or any other CHILD SA, as far as IKEv2 is concerned. Hence this set
>>of TSi & TSr values have no bearing to the set of TSi & TSr values present
>>in the CRETE_CHILD_SA exchange.
>>
>OK.
>If the responder only accepts a subset of the proposed traffic selectors,
>does the initiator change its
>SPD?
Reply: If the responder only accepts a subset of the proposed traffic selectors, the internal policies of the two peers will determine whether the initiator will have to change its SPD policies. In many cases the initiator won't have to because the responder have accepted only a subset of the proposed traffic selectors because the responder's internal policy dictates that each subset of the proposed traffic selectors should have a separate CHILD Sa. In such a case, the initiator will create separate CHILD SAs with the different subsets of traffic selectors from the original traffic selector set.
But in cases where the initiator is assigned an internal IP address by the responder (like in a case a remote user is trying to connect to his office security gateway) in a Config payload, the SPD of the initiator will need to be updated with the assigned IP address.

>
>Thank you very much.
>
>Sincerely,
>fan
>
>
>Regards
>>Dipanjan Datta
>>
>>
>>On Thu, 14 Jun 2007 fan zhao wrote :
>> >Hi,
>> >
>>   <http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/signature-home.htm/1050715198@Middle5/1222036_1215847/1221230/1?PARTNER=3&OAS_QUERY=null+target=new+>