Subject: [IPsec] Complexing of Traffic Selector (TSi & TSr)

From: Jaemin Park <[email-masked]>
Date: Fri, 18 Jun 2010 23:51:01 +0900

Dear All,

I'm in charge of developing VPN Clients based on IKEv2 and IPSec.

We referred to the implementation of strongswan and RFC documents such as
4306 and 4718.

While developing, we faced one question about complexing of Traffic
Selectors.
According to the RFC 4718, complexing of TSi and TSr which have same
protocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) and TSr is (ip any any)
where protocol IDs are different, should VPN complex TSi and TSr?
According to the implementation of strongswan, we could find the fact that
the strongswan is checking when complexing the TSi and TSr as follows :
1) remove the policy which has different protocol IDs for TSi and TSr as
long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY"
According to my analysis, following examples can be possible :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP & UDP yields UDP
- TCP & UDP <-- remove this case

Does above implementation of strongswan follow the standards?
If so, we're planning to implement the way the strongswan supports.

I'm looking forward to all of the experts' responses.

My Best Regards,
Jaemin Park

-- 
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010-2658
T  : +82-2-2010-9255
[email-masked], [email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 18 Jun 2010 11:07:37 -0400

Hi Jaemin,

The RFC allows you to narrow the proposed traffic selectors to something
smaller than what the peer proposes.  From your description, it sounds like
StrongSwan has made a pragmatic choice to narrow the proposed selectors to
something symmetrical.  This is allowed by the RFC.  The TCP&UDP case is a
strange one, and in particular it doesn't accomplish much for TCP, but it
is allowed by the RFC.  If your SPD and/or SAD pragmatically do not allow
you to express this sort of asymmetry for IPsec-protected traffic, then it
is proper for you to respond with TS_UNACCEPTABLE to such a proposal.  You
will of course be unable to interoperate with a peer making such a
proposal, but in this case I'm not sure that is a great hardship.

Also don't forget to take into account complex proposals containing more
than one traffic selector for TSi and/or TSr.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Jaemin Park <[email-masked]>                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  [email-masked]                                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |06/18/2010 10:51 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[IPsec] Complexing of Traffic Selector (TSi & TSr)                                                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

Dear All,

My Best Regards,
Jaemin Park

--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010-2658
T  : +82-2-2010-9255
[email-masked], [email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jaemin Park <[email-masked]>
Date: Sun, 20 Jun 2010 02:45:40 +0900

Hi, Scott,

I want to ask one more thing about Traffic Selector.

In my case, host A and host B are working as follows about Traffic Selector
:

1) host A (initiator) sends TS to host B (responder)
2) host B narrows the TS sent by host A and responses the narrowed TS to
host A

At this point, the narrowed TS includes the TSs that violates the policy of
initiator such as different protocol IDs of TSi and TSr, etc.
Then, can host A (initiator) also narrow the narrowed TSs, that is to remove
the case of which the protocol IDs are different?

I'm looking forward to responses.

Thanks in advance.

My Best Regards,
Jaemin Park

On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen <[email-masked]> wrote:

> strange one, and in particular it doesn't accomplish much for TCP, but it is
> allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to
> express this sort of asymmetry for IPsec-protected traffic, then it is
> proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will
> of course be unable to interoperate with a peer making such a proposal, but
> in this case I'm not sure that is a great hardship.
>
> [image: Inactive hide details for Jaemin Park ---06/18/2010 10:51:53
> AM---Dear All,]Jaemin Park ---06/18/2010 10:51:53 AM---Dear All,
>
>
> From:
> Jaemin Park <[email-masked]>
> To:
> [email-masked]
> Date:
> 06/18/2010 10:51 AM
> Subject:
> [IPsec] Complexing of Traffic Selector (TSi & TSr)
> ------------------------------
>
>
>
> Dear All,
>
> T  : +82-2-2010-9255  *
> *
> [email-masked]* <[email-masked]>, [email-masked]* <[email-masked]>

---

From: Raj Singh <[email-masked]>
Date: Sun, 20 Jun 2010 11:06:15 +0530

Hi Jaemin,

If initiator narrows down the TSr, then
1. the responder is not aware of initiator has narrowed down TSr and if it
initiates a traffic which is from a broader section of range which Initiator
has not accepted, there will data black-hole.
2. I think, better solution will be, If initiator has to narrow down the
TSr, it can delete old Child SA and negotiate a new Child SA based on
knowledge of TSr that are acceptable to initiator as well as responder.

Regards,
Raj

On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park <[email-masked]> wrote:

> Then, can host A (initiator) also narrow the narrowed TSs, that is to
> remove the case of which the protocol IDs are different?
>
> On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen <[email-masked]>wrote:
>
>>  Hi Jaemin,
>>
>> However, in the case when TSi is (17 (udp) any any) and TSr is (ip any
>> any) where protocol IDs are different, should VPN complex TSi and TSr?
>> [email-masked]* <[email-masked]>, [email-masked]*<[email-masked]>

---

From: Jaemin Park <[email-masked]>
Date: Sun, 20 Jun 2010 16:36:22 +0900

Dear All,

I need to clarify my question.
My question is about the way for initiator to complex the TS narrowed  
by responder.

Suppose that following TSs are returned by the responder.

1) TSi = (TS1, TS2)
2) TSr = (TS3, TS4, TS5)

While complexing, the case TS1 and TS5 need to be removed by initiator  
due to the difference of protocol ID and     violation of the intended  
policy.

Can initiator remove the above case and follow the RFC?

I'm looking forward to the experts' responses.

Thanks in advance.

 From My iPhone

2010. 6. 20. 오후 2:36 Raj Singh <[email-masked]> 작성:

> 1. the responder is not aware of initiator has narrowed down TSr and  
> if it initiates a traffic which is from a broader section of range  
> which Initiator has not accepted, there will data black-hole.
> 2. I think, better solution will be, If initiator has to narrow down  
> the TSr, it can delete old Child SA and negotiate a new Child SA  
> based on knowledge of TSr that are acceptable to initiator as well  
> as responder.
>
> Regards,
> Raj
>
>
> In my case, host A and host B are working as follows about Traffic  
> Selector :
>
> 2) host B narrows the TS sent by host A and responses the narrowed  
> TS to host A
>
> At this point, the narrowed TS includes the TSs that violates the  
> policy of initiator such as different protocol IDs of TSi and TSr,  
> etc.
> Then, can host A (initiator) also narrow the narrowed TSs, that is  
> to remove the case of which the protocol IDs are different?
>
> The RFC allows you to narrow the proposed traffic selectors to  
> something smaller than what the peer proposes. From your  
> description, it sounds like StrongSwan has made a pragmatic choice  
> to narrow the proposed selectors to something symmetrical. This is  
> allowed by the RFC. The TCP&UDP case is a strange one, and in  
> particular it doesn't accomplish much for TCP, but it is allowed by  
> the RFC. If your SPD and/or SAD pragmatically do not allow you to  
> express this sort of asymmetry for IPsec-protected traffic, then it  
> is proper for you to respond with TS_UNACCEPTABLE to such a  
> proposal. You will of course be unable to interoperate with a peer  
> making such a proposal, but in this case I'm not sure that is a  
> great hardship.
>
> Also don't forget to take into account complex proposals containing  
> more than one traffic selector for TSi and/or TSr.
>
>
> Jaemin Park ---06/18/2010 10:51:53 AM---Dear All,
>
> From:	
> We referred to the implementation of strongswan and RFC documents  
> such as 4306 and 4718.
>
> However, in the case when TSi is (17 (udp) any any) and TSr is (ip  
> any any) where protocol IDs are different, should VPN complex TSi  
> and TSr?
> According to the implementation of strongswan, we could find the  
> fact that the strongswan is checking when complexing the TSi and TSr  
> as follows :
> 1) remove the policy which has different protocol IDs for TSi and  
> TSr as long as both of them are not "ANY"
> [email-masked],  
> [email-masked]
> IPsec mailing list
> [email-masked]

---

From: Raj Singh <[email-masked]>
Date: Mon, 21 Jun 2010 19:11:24 +0530

Hi Jaemin,

The problem is at initiator side, when its sending its TSi/TSr, it sending
some range which is violating its own policies. This is not allowed by RFC
as per section 2.9.1.

Regards,
Raj

2010/6/20 Jaemin Park <[email-masked]>

> My question is about the way for initiator to complex the TS narrowed by
> responder.
>
> While complexing, the case TS1 and TS5 need to be removed by initiator due
> to the difference of protocol ID and     violation of the intended policy.
>
> On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park < <[email-masked]>
> [email-masked]> wrote:
>
>> Hi, Scott,
>>
>> At this point, the narrowed TS includes the TSs that violates the policy
>> of initiator such as different protocol IDs of TSi and TSr, etc.
>> On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen < <[email-masked]>
>> [email-masked]> wrote:
>>
>>>  Hi Jaemin,
>>>
>>> Scott Moonen ( <[email-masked]>[email-masked])
>>> <http://www.linkedin.com/in/smoonen>http://www.linkedin.com/in/smoonen
>>>
>>> Jaemin Park < <[email-masked]>[email-masked]>
>>> To: 
>>> <[email-masked]>[email-masked] 
>>> Date: 
>>>
>>> 06/18/2010 10:51 AM
>>> Subject: 
>>>
>>> According to the implementation of strongswan, we could find the fact
>>> that the strongswan is checking when complexing the TSi and TSr as follows :
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/ipsec>
>> <[email-masked]>[email-masked], <[email-masked]>[email-masked]
>>
>>  <[email-masked]>[email-masked]
>>  <https://www.ietf.org/mailman/listinfo/ipsec>