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 <rsjen...@gmail.com> 작성:
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 <jmpar...@gmail.com>
wrote:
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
<smoo...@us.ibm.com> wrote:
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 (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
<graycol.gif>Jaemin Park ---06/18/2010 10:51:53 AM---Dear All,
<ecblank.gif>
From: <ecblank.gif>
Jaemin Park <jmpar...@gmail.com>
<ecblank.gif>
To: <ecblank.gif>
ipsec@ietf.org
<ecblank.gif>
Date: <ecblank.gif>
06/18/2010 10:51 AM
<ecblank.gif>
Subject: <ecblank.gif>
[IPsec] Complexing of Traffic Selector (TSi & TSr)
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
jmp...@kt.com,
jmpar...@gmail.com_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010-2658
T : +82-2-2010-9255
jmp...@kt.com, jmpar...@gmail.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
