Oops, here is the missing net-net-scenario.txt file.
Andreas Steffen wrote:
> Hello Mugur,
>
> the idea is not to establish multiple IKE_SA, but multiple CHILD_SAs
> with identical traffic selectors. Take the ikev2/net2net-cert UML
> scenario as an example:
>
> sun ~ # ipsec start
> moon ~ # ipsec start
> moon ~ # ipsec up net-net
> moon ~ # ping -c 2 -I 10.1.0.1 10.2.0.1
> moon ~ # ipsec up net-net
> moon ~ # ipsec up net-net
> moon ~ # ping -c 2 -I 10.1.0.1 10.2.0.1
>
> results in 1 IKE_SA to be established plus 3 CHILD_SAs as can be seen
> in the attached file net-net-scenario.txt. Assigning different QoS
> classes to generated multiple IPsec SAs, actually to their SPIs, is out
> of the scope of the IKEv2 protocol.
>
> Multiple IKE_SAs can only occur if both peers start an IKE negotiation
> simultaneously.
>
> Best regards
>
> Andreas
>
> ABULIUS, MUGUR (MUGUR) wrote:
>> Hello Andreas,
>> Do you have any plan to allow for more than one IKE_SA between two peers?
>> This may help for enhanced QoS class management.
>> Best Regards
>> Mugur
>>
>> -----Original Message-----
>> From: Andreas Steffen [mailto:andreas.stef...@strongswan.org]
>> Sent: samedi 26 décembre 2009 18:59
>> To: ABULIUS, MUGUR (MUGUR)
>> Cc: users@lists.strongswan.org; Pisano, Stephen G (Stephen); ROSSI, MICHEL
>> MR (MICHEL); SCARAZZINI, FABRICE (FABRICE)
>> Subject: Re: [strongSwan] Several TS on a same connection
>>
>> Hello Mugur,
>>
>> currently the Linux kernel copies the TOS field from the encapsulated IP
>> packets into the IP header of the ESP packet.
>> Thus routers can treat the QoS classes differently. Problems may arise in
>> the presence of large congestion where ESP packets with low QoS priority are
>> delayed more than the default IPsec replay window size of 32 packets and
>> thus will be dropped upon late arrival.
>>
>> The IKEv2 standard explicitly does *not* support the negotiation of QoS
>> classes but allows the setup of parallel IPsec SAs for this purpose:
>>
>> Note that IKEv2 deliberately allows parallel SAs with the same
>> traffic selectors between common endpoints. One of the purposes of
>> this is to support traffic quality of service (QoS) differences among
>> the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]).
>> Hence unlike IKEv1, the combination of the endpoints and the traffic
>> selectors may not uniquely identify an SA between those endpoints, so
>> the IKEv1 rekeying heuristic of deleting SAs on the basis of
>> duplicate traffic selectors SHOULD NOT be used.
>>
>> RFC 4306, page 22
>>
>> Regards
>>
>> Andreas
>>
>> BULIUS, MUGUR (MUGUR) wrote:
>>> Andreas,
>>>
>>> I have a concern regarding QoS and your statement:
>>>
>>> "---One of our pending projects intends to create multiple tunnels for
>>> different QoS classes but this would require some fundamental changes
>>> in the Linux kernel." (Do you have a roadmap for this?). ---"
>>>
>>>
>>> This suggests that using different QoS classes today for different
>>> IPsec-ed data flows between the same peers should be discouraged (as
>>> QoS can be used for routing decisions and all data flows are on the
>>> same IPsec tunnel) and that there is no way today, via strongSwan
>>> configuration, to safely affect different QoS values for different
>>> IPsec-ed flows between two peers?
>>>
>>> Best Regards Mugur
======================================================================
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
moon ~ # ipsec statusall
Status of IKEv2 charon daemon (strongSwan 4.3.6dr6):
uptime: 4 minutes, since Dec 27 14:55:40 2009
worker threads: 9 idle of 16, job queue load: 0, scheduled events: 3
loaded plugins: curl aes des sha1 sha2 md5 pem pkcs1 gmp random x509 hmac
xcbc stroke kernel-netlink updown
Listening IP addresses:
192.168.0.1
fec0::1
10.1.0.1
fec1::1
Connections:
net-net: 192.168.0.1...192.168.0.2
net-net: local: [moon.strongswan.org] uses public key authentication
net-net: cert: "C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
net-net: remote: [sun.strongswan.org] uses any authentication
net-net: child: 10.1.0.0/16 === 10.2.0.0/16
Security Associations:
net-net[1]: ESTABLISHED 4 minutes ago,
192.168.0.1[moon.strongswan.org]...192.168.0.2[sun.strongswan.org]
net-net[1]: IKE SPIs: b5ad30487ae0a7b3_i* 23b481325f57efd2_r, public key
reauthentication in 48 minutes
net-net[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
net-net{1}: INSTALLED, TUNNEL, ESP SPIs: c6138f22_i c70a3446_o
net-net{1}: AES_CBC_128/HMAC_SHA1_96, 168 bytes_i (40s ago), 168 bytes_o
(40s ago), rekeying in 11 minutes
net-net{1}: 10.1.0.0/16 === 10.2.0.0/16
net-net{2}: INSTALLED, TUNNEL, ESP SPIs: c7e72752_i c142ca2e_o
net-net{2}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in
13 minutes
net-net{2}: 10.1.0.0/16 === 10.2.0.0/16
net-net{3}: INSTALLED, TUNNEL, ESP SPIs: cd285f04_i c8192965_o
net-net{3}: AES_CBC_128/HMAC_SHA1_96, 168 bytes_i (2s ago), 168 bytes_o
(2s ago), rekeying in 16 minutes
net-net{3}: 10.1.0.0/16 === 10.2.0.0/16
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
