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]== _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
