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