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:[email protected]] Sent: samedi 26 décembre 2009 18:59 To: ABULIUS, MUGUR (MUGUR) Cc: [email protected]; 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 [email protected] 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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
