Re: [strongSwan] liveness mechanism for BITW IPsec
Hi Martin, I assume you are using a custom kernel backend for ESP processing? We are not using a custom kernel backend. Our application uses the netlink socket interface and sets-up the cryptographic HW engine with SA events from strongSwan. The Linux parameters disable_xfrm and disable_policy are set to 1. Best Regards Mugur -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: lundi 4 août 2014 11:36 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); DIMA, CIPRIAN (CIPRIAN); WASNIEWSKI, ALAIN (ALAIN) Subject: Re: [strongSwan] liveness mechanism for BITW IPsec Hi Mugur, There is any way to tell to strongSwan that there is traffic in order to avoid sending INFORMATIONAL messages in this case? strongSwan queries the kernel-interface for SA usage. If you are using kernel-netlink as backend, Linux usually provides this information when querying the SA/SP state. In our Bump In The Wire IPsec implementation I assume you are using a custom kernel backend for ESP processing? If yes, you may consider adding the appropriate information in your kernel interface when quering usage statistics with query_sa() or query_policy(). Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] liveness mechanism for BITW IPsec
Hi Martin in the end you'll just have to respond appropriately to the XFRM_MSG_GETSA/XFRM_MSG_GETPOLICY requests with SA usage information Thank you Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] liveness mechanism for BITW IPsec
Hello, In our Bump In The Wire IPsec implementation (strongSwan 4.5.2-al4) the INFORMATIONAL messages are periodically sent even if there is traffic on the tunnel. Since the tunnel traffic is not seen by Linux this seems normal. There is any way to tell to strongSwan that there is traffic in order to avoid sending INFORMATIONAL messages in this case? Thank you for help Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] SHA-256 for IKE_AUTH (IKEv2) ?
Hello Andreas, strongSwan only supports SHA-1 with the RSA Digital Signature AUTH payload Thank you very much for clarification. Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] SHA-256 for IKE_AUTH (IKEv2) ?
Hello, Can you please specify if StrongSwan supports for IKEv2 Authentication Payload RSA Digital signatures using SHA-256 as hash function? The RFC 5596 (IKEv2) at §3.8 Authentication Payload makes reference to RSAES-PKCS1-v1_5 signature scheme for which the RFC 3447 includes SHA-256. Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Does the eNB Srongswan support up to 20 trust anchors?
Hello, Our application using StrongSwan requires up to 20 trust anchors in the CERTREQ payload. Can you please specify which are theoretical/practical limitations for this number? Does StrongSwan loop over the list of trust anchors up to the first match (if any) and then stops? Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Does the eNB Srongswan support up to 20 trust anchors?
Hi Martin, Thanks for the very useful information. Regards, Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Authentication of a CERT payload with only the subject certificate
Hi Andreas, Martin Thanks for your quick answers. kind regards, Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] CRLs over IPsec tunnels
Hi Martin, CRL fetching is delegated to libcurl (http://curl.haxx.se/libcurl/). Thanks. According http://curl.haxx.se/mail/lib-2012-11/0079.html and http://curl.haxx.se/mail/lib-2012-11/0080.html, libcurl uses a hardcoded value (=80) Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] CRLs over IPsec tunnels
Hi Martin, Fetching a CRL inside the tunnel to check the certificate status for the same tunnel does not work: it is a hen-egg problem. With a strict CRL policy, you can't establish the tunnel, because you have no CRL. And you can't fetch a CRL, because you don't have a tunnel yet. In case CRLs are retrieved outside this tunnel, can you please confirm that: 1)Charon HTTP requests use the protocol and port from /etc/services (e.g. TCP/80)? 2)Charon supports the rfc3986 - Uniform Resource Identifier (URI): Generic Syntax? Best Regards Mugur Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] CRLs over IPsec tunnels
Hello, Can you help please to determine if there are any issues at initialization and during the life of an IPsec tunnel if CRLs are retrieved via this same IPsec tunnel? There are any additional issues if the connection uses the configuration payload in order to request a Virtual IP to peer? The strictcrlpolicy may be : yes or ifuri Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] CRLs over IPsec tunnels
Hi Martin, Thank you for clarification Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] CRLs over IPsec tunnels
Thank you Andreas for this usefull information Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] IKE_SA_INIT timeout management
Hello, Can be please confirmed that IKEv2 retransmission algorithm based on charon.retransmit_base charon.retransmit_timeout charon.retransmit_tries applies as well to IKE_SA_INIT request? Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKE_SA_INIT timeout management
Hi Martin, Thank you for reply. Yes, those options apply to IKE_SA_INIT requests as well. However, IKE_SA_INIT requests are additionally affected by the keyingtries Does 'keyingtries' always supersede 'retransmit_tries' or only when is smaller? Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] RFC 4325 support - Authority Information Access CRL Extension
Hi Andreas, Happy New Year to all at the strongSwan team! Sorry to ask again. I am confused about the sentence: the only alternative to extracting http CDPs from end entity certificates is to define additional CDPs in ipsec.conf in a special ca section Is this sentence true only in relation with AIA extension (RFC 4325), or it is a general strongSwsan statement for retrieving CRLs? Assuming that a X.509 certificate has a CDP extension but ***NOT*** an AIA extension, do you mean that strongSwan can't retrieve the CRL unless the CDP is (also) specified in ipsec.conf (it is already specified inside X.509 certificate)? In any case, and regardless the answer to previous question, we need to address the validation of retrieved CRL that was signed by a specific CA (CA1). My assumption is that strongSwan needs to be commissioned with the certificate of CA1 in order to be able to validate the CRL. So the question: By which ipsec.conf option should be specified and in which directory should be present the certificate of CA1 to be used by strongSwan for CRL validation. Thank you Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: mercredi 14 décembre 2011 21:07 To: ABULIUS, MUGUR (MUGUR) Cc: Martin Willi; SCARAZZINI, FABRICE (FABRICE); Pisano, Stephen G (Stephen); users@lists.strongswan.org; WASNIEWSKI, ALAIN (ALAIN) Subject: Re: [strongSwan] RFC 4325 support - Authority Information Access CRL Extension Hello Mugur, have a look at my inline comment. Regards Andreas On 14.12.2011 15:24, ABULIUS, MUGUR (MUGUR) wrote: Hello Martin, No, we currently don't support the Authority Information Access extension in CRLs. Thank you for answer. 1. Which is the behavior of strongSwan when it receives a X.509 certificate with an AIA extension? The extension is ignored or there is some specific processing? Here is the code which processes the AIA extension: http://wiki.strongswan.org/projects/strongswan/repository/revisions/master/entry/src/libstrongswan/plugins/x509/x509_cert.c#L603 As you can see we currently extract OCSP URIs only. 2. We are looking for a way to validate CRLs signed with different keys (possibly by different CAs) as certificates referencing these CRLs. For this scenario the local system has, by some other means, the X.509 certificate of signing CA for CRL. How these X.509 certificates should be specified to strongSwan (via which options or/and using which directories) to validate the CRL ? Currently the only alternative to extracting http or ldap CDPs from end entitcy certificates is to define additional CDPs in ipsec.conf in a special ca section. Regards Mugur Regards Andreas == 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
[strongSwan] Connection continuously going up and down
Hello, The ALPHA connection continuously goes up and down if '/etc/ipsec.d/cacerts' contains 2 certificates that are the same. In this test the CAs hierarchy has only one level (the anchor is the certificate of the signing CA of the local system). The local system (initiator of IKE connection) is a Linux system. We know that is unusual to have 2 files containing the same certificate in 'cacerts' but this may happen for our application in the field. Is the strongSwan behavior normal or there is a bug? conn ALPHA left=172.21.11.21 right=172.21.11.181 leftsubnet=172.21.10.21/32 rightsubnet=0.0.0.0/0,0::0/0 leftauth=pubkey rightauth=pubkey leftcert=0_clcert.der rightca=O=Company, CN=CMS rightid=O=*, CN=* auto=start Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] RFC 4325 support - Authority Information Access CRL Extension
Hello Andreas, the only alternative to extracting http CDPs from end entitcy certificates is to define additional CDPs in ipsec.conf in a special ca section Thank you. Assuming that the retrieved CRL was signed by CA1, my question is: Does strongSwan expects a X.509 certificate with a subject name CA1 in /etc/ipsec.d/cacerts to check/validate the signature of the CRL? Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] RFC 4325 support - Authority Information Access CRL Extension
Hello, Does Charon support the Authority Information Access CRL Extension as specified by the RFC 4325? If this extensions is supported, can be specified please in few words how is retrieved, where is stored, when and how is used by strongSwan the certificate of the CRL issuer from this extension. Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] RFC 4325 support - Authority Information Access CRL Extension
Hello Martin, No, we currently don't support the Authority Information Access extension in CRLs. Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] RFC 4325 support - Authority Information Access CRL Extension
Hello Martin, No, we currently don't support the Authority Information Access extension in CRLs. Thank you for answer. 1. Which is the behavior of strongSwan when it receives a X.509 certificate with an AIA extension? The extension is ignored or there is some specific processing? 2. We are looking for a way to validate CRLs signed with different keys (possibly by different CAs) as certificates referencing these CRLs. For this scenario the local system has, by some other means, the X.509 certificate of signing CA for CRL. How these X.509 certificates should be specified to strongSwan (via which options or/and using which directories) to validate the CRL ? Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] /etc/ipsec.d/crls directory when charon is started
Hello, Does charon remove CRLs files cached from /etc/ipsec.d/crls directory when started ? Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] How to bypass CRL checks?
Hello Stephen, Thanks again. I have seen at http://wiki.strongswan.org/projects/strongswan/wiki/Autoconf that plug-ins are specified at strongSwan binary creation (./configure). There is any way when strongSwan is load to make the choice of plug-ins to load (e.g. revocation). Which is the best strongSwan deployment policy when some runs need the revocation plug-in and some other runs do not need the plug-in. Context: Charon under Linux Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: jeudi 24 novembre 2011 12:51 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); Pisano, Stephen G (Stephen); WASNIEWSKI, ALAIN (ALAIN) Subject: Re: [strongSwan] How to bypass CRL checks? Hello Mugur, with IKEv2 revocation checks can be easily disabled by not loading the revocation plugin. What is not possible is to disable CRL checking on a per connection definition basis. Regards Andreas On 11/24/2011 08:50 AM, ABULIUS, MUGUR (MUGUR) wrote: Hello, Our understanding in case of setting strictcrlpolicy to **no** for charon is that strongSwan denies the authentication if the certificate appears in the fetched CRL. But, if the certificate does not specify an uri or if the CRL can't be fetched the authentication is not denied. Can you please check our understanding? In case our assumption is correct we are looking for a way to set-up strongSwan (for some specific run scenarios) to bypass any CRL checks (even if strictcrlpolicy=no). We are looking for this capability even if received certificates specify an uri and the corresponding CRL can be fetched from CDP. Thank you 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
[strongSwan] Which source IP@ is used to retrieve CRLs?
Hi, Assuming the ipsec.conf defines several connections with different left= and right= values, which source IP@ is used by strongSwan to retrieve CRLs from a CDP? In our case URI is a HTTP URI. Charon is used. Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Which source IP@ is used to retrieve CRLs?
Hi Andreas, Thank you for answer. I wondered if strongSwan does not use a 'bind(2)' syscall to force the source IP@ for corresponding sockets. But from your answer this seams to not be the case. Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: mercredi 23 novembre 2011 19:30 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); Pisano, Stephen G (Stephen); WASNIEWSKI, ALAIN (ALAIN) Subject: Re: [strongSwan] Which source IP@ is used to retrieve CRLs? Hello Mugur, I don't quite understand your question. Charon does a HTTP-based CRL fetch using either the curl or soup plugin. The source IP of the HTTP request belongs to charon's network interface via which the daemon is able to reach the HTTP server. Regards Andreas On 11/23/2011 05:53 PM, ABULIUS, MUGUR (MUGUR) wrote: Hi, Assuming the ipsec.conf defines several connections with different left= and right= values, which source IP@ is used by strongSwan to retrieve CRLs from a CDP? In our case URI is a HTTP URI. Charon is used. 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
[strongSwan] How to bypass CRL checks?
Hello, Our understanding in case of setting strictcrlpolicy to **no** for charon is that strongSwan denies the authentication if the certificate appears in the fetched CRL. But, if the certificate does not specify an uri or if the CRL can't be fetched the authentication is not denied. Can you please check our understanding? In case our assumption is correct we are looking for a way to set-up strongSwan (for some specific run scenarios) to bypass any CRL checks (even if strictcrlpolicy=no). We are looking for this capability even if received certificates specify an uri and the corresponding CRL can be fetched from CDP. Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Different values for the option strictcrlpolicy
Hi Martin, Thank you for your help. On our strongSwan systems we want to switch on/off the CRL checks. If the check is switched off then even if received certificate specifies a CDP extension toward an accessible remote CRL we don't want that strongSwan rejects the IKE connection even if the serial number of certificate is specified by the CRL as no more valid. Do you think that we can set-up strongSwan for this capability? If yes what should be the value for strictcrlpolicy in this case? Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Different values for the option strictcrlpolicy
Hello, We are running Charon with the strictcrlpolicy option. Because the option is part of the config setup section my understanding is that the same value of the option applies to all connections in ipsec.conf. However, our system has connections (IPsec tunnels) with several customers and they have different requirements. One of them wants for his connections the behavior as for strictcrlpolicy=no, another one as for strictcrlpolicy=ifuri and the third one as for strictcrlpolicy=yes. There is any way to satisfay all three cases from the same strongSwan instance? Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Different values for the option strictcrlpolicy
Hi Martin, Is the introduction of this new option planned for the near future? Best Regards Mugur -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: vendredi 18 novembre 2011 14:55 To: ABULIUS, MUGUR (MUGUR) Cc: 'users@lists.strongswan.org'; Pisano, Stephen G (Stephen) Subject: Re: [strongSwan] Different values for the option strictcrlpolicy Hi, One of them wants for his connections the behavior as for strictcrlpolicy=no, another one as for strictcrlpolicy=ifuri and the third one as for strictcrlpolicy=yes. There is any way to satisfay all three cases from the same strongSwan instance? Charon internally handles CRL policies per connection (or even per authentication round when using multiple rounds). But Pluto can't, and therefore there is a global option in ipsec.con only. We'd have to introduce a new ipsec.conf connection keyword and pass this information to the daemon; no rocket science, but needs some work. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Augment the esp cipher suites with foreign not standard ciphers
Hi Martin, Adding a new ESP cipher is possible, but not straight forward. You'll need to add support in several layers: 1) First, of course, the kernel needs support for this algorithm in the crypto API 2) The kernel needs support for the new algorithm in the XFRM subsystem. 3) Choose an IKEv2 algorithm identifier (in private space?) for your algorithm 4) Add a proposal configuration option for the algorithm identifier 5) Extend the kernel interface by the new cipher We intercept the SA flow between strongSwan and kernel by our user mode agent using PF_KEY sockets and we disable Linux IPsec-ing with disable_xfrm disable_policy. The IP data flow is not IPsec-ed by Linux but by an external NPU. Then, probably only the items 3) and 4) from your list are required. Concerning the item 3, if we choose an IKEv2 algorithm identifier then how we can specify it with strongSwan? I don't understand what is and what should be done for the item 4 (proposal configuration option). A simple but not elegant solution is to negotiate a well-known/supported Cipher but, by convention, to apply to the both ends of the tunnel the new cipher (not related to negotiated one). Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] How to use cacert directory
Hello, In my configuration the strongSwan system initiates IKEv2 connections with two different Securities Gateways (SEGs) and uses two distinct certificates (leftcert=) for them. In general, the certificates for each SEG are administered by different entities. Certificates in the strongSwan system are commissioned independently by these two entities. Concerning strongSwan configuration I intend to put all the chain of certificates concerning a remote SEG in a separate cacert directory (specified with a ca section). E.g. /etc/ipsec.d/cacert1 and /etc/ipsec.d/ceacert2. I don't intend to use /etc/ipsec.d/certs. Can you please confirm that: * This is a correct configuration for strongSwan? * Does strongSwan accept sub-directories in 'cacert1' and 'cacert2' (empties or not)? * Does strongSwan looks (by default) for certificates also in the sub-directories created in 'cacert1' and 'cacert2'. * It may be possible that the certificates from 'cacert1' and 'cacert2' to be identical (but probably not their file name), unless the local certificates that are always different. Is this configuration valid for strongSwan? Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] About leftca and rightca
Hello, For left|rightca the ConnSection documentation says: the distinguished name of a certificate authority which is required to lie in the trust path going from the left|right participant's certificate up to the root certification authority. Can you confirm please that the rightca is the distinguished name of the CA used by the local system to designate its unique trust anchor via the CERTREQ payload? If this assumption is true, can you please confirm that a certificates whose SubjectName having the same value as rightca must reside in /etc/ipsec.d/cacerts/? I am not able to figure out the exact meaning of leftca and how it is used by strongSwan in the authentication process and within the IKE_AUTH message exchange (if ever). Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] PKCS#10 file format with ipsec pki -req
Hello, The Synopsis and examples of ipsec pki -req command at http://wiki.strongswan.org/projects/strongswan/wiki/IpsecPkiReq suggest that the only supported output format of a certificate request file is binary DER. How can be created a certificate request file in a PEM format with strongSwan commands? Does this command accept both DER and PEM as private key RSA input file (--in) ? Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] PKCS#10 file format with ipsec pki -req
Hi Martin, the only supported output format of a certificate request file is binary DER. For which reason one will choose ipsec pki -req on a strongSwan system instead openssl to generate certificate request files in DER format? More general question: Do you know which one of DER or PEM formats are most widely used by various PKI related tools for certificate request files? Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Any limit on repeated rekeying using CREATE_CHILD_SA?
Hello, How strongSwan addresses the following RFC4306 requirement? There is any strongSwan parameter to manage the CREATE_CHILD_SA exchange? [[[...Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key or overrun of either endpoint. Implementers should take note of this fact and set a limit on CREATE_CHILD_SA exchanges between exponentiations...]]] Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Narrowing TS for a specific host
strongSwan specific feature or it is specified by a RFC? It is strongSwan specific, other implementations might do this differently. You'll have to check this with your other implementation, maybe there are ways to do this manually. Regards Martin Similarly I wish to apply to SCTP packets a cipher suite that supersedes the cipher suite to be applied to all other packets from the same IP@ (i.e. 10.5.0.1). Can this be done by strongSwan with the example below? If yes, is this a standard (RFC) feature or strongSwan specific? Finally, what assumption can be done for priorities of policies installed by to-HOST relative to SCTP from the same example? conn to-HOST also=host-host leftsubnet=10.5.0.1 rightsubnet=10.6.0.2 esp=specific_1 auto=start conn SCTP also=host-host leftsubnet=10.5.0.1 rightsubnet=0.0.0.0/0 rightprotoport=SCTP leftprotoport=SCTP esp=specific_2 auto=start conn to-WORLD also=host-host leftsubnet=10.5.0.1 rightsubnet=0.0.0.0/0 esp=specific_3 auto=start conn host-host left=IP address of left right=IP address of right Best Regards Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Narrowing TS for a specific host
Hello Martin, Thank you for answer. By which way the priority of a policy can be specified into 'ipsec.conf' file? Can you please confirm that the line rightsubnet=%any should be replaced by rightsubnet=0.0.0.0/0? More exactly, which will be the correct 'ipsec.conf' for my example? Thank you Mugur -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: mardi 19 janvier 2010 11:37 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); ROSSI, MICHEL MR (MICHEL); Salvarani, Alexandro (Alex); Pisano, Stephen G (Stephen) Subject: Re: [strongSwan] Narrowing TS for a specific host Hi, conn to-WORLD-unless-HOST1and2 There is no way to exclude specific hosts from a TS. But if you have multiple tunnels, more specific ones match with a higher priority. rightsubnet=0.0.0.0/0 includes all traffic. If a another tunnel is up to a specific IP, that policy should have a higher priority and it is used for this target address. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Narrowing TS for a specific host
Hello Martin, Is this feature ...smaller subnets are always installed with a higher priority a strongSwan specific feature or it is specified by a RFC? If the feature is strongSwan specific, then the configuration below may not behave as expected if the other end of the tunnel is not strongSwan. Recall: the goal is the cipher for traffic originating from 10.5.0.1 to be specific_3, unless if destination is HOST1 or 2. conn to-HOST1 also=host-host leftsubnet=10.5.0.1 rightsubnet=10.6.0.2 esp=specific_1 auto=start conn to-HOST2 also=host-host leftsubnet=10.5.0.1 rightsubnet=10.6.0.3 esp=specific_2 auto=start conn to-WORLD also=host-host leftsubnet=10.5.0.1 rightsubnet=0.0.0.0/0 esp=specific_3 auto=start conn host-host left=IP address of left right=IP address of right Mugur -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: mardi 19 janvier 2010 14:40 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; SCARAZZINI, FABRICE (FABRICE); Salvarani, Alexandro (Alex); ROSSI, MICHEL MR (MICHEL); Pisano, Stephen G (Stephen) Subject: RE: [strongSwan] Narrowing TS for a specific host By which way the priority of a policy can be specified into 'ipsec.conf' file? There is currently no way of specifying priorities manually in ipsec.conf. But smaller subnets are always installed with a higher priority. [...] should be replaced by rightsubnet=0.0.0.0/0? Yes, rightsubnet=0.0.0.0/0 includes all destination addresses. Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Different esp chiper suites for a same tunnel?
Hello, Does strongSwan allow different esp = cipher suites for different conn name directives of a same tunnel? Example: conn proto1 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.6.0.0/16 leftprotoport=tcp rightprotoport=tcp/http esp=aes128-sha256-modp2048! //=== auto=start conn proto2 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.6.0.0/16 leftprotoport=tcp rightprotoport=tcp/smtp auto=start esp=aes128ctr-aesxcbc-modp2048! //== conn host-host left=IP address of left right=IP address of right Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Several TS on a same connection
Hello Andreas, Thank you very much So, each conn corresponds to exactly one CHILD_SA Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: dimanche 27 décembre 2009 14:42 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 ABULIUS, MUGUR (MUGUR) wrote: Andreas, Thank you again for responding. Indeed, the explanation concerning asymmetry for leftprotoport= and rightprotoportin= is quite simple. Do you confirm that calling: ipsec up net-net on the 'net-net' connection from your example will create IPsec SAs only corresponding to conn net-net and to conn host-host (because specified by also=host-host), but connections conn proto1 and conn proto2 are not started yet? If you use the option auto=start then all three tunnels are started automatically when the daemon starts up with ipsec start, with the first connection establishing the IKE_SA. With the option auto=add you must start all tunnels manually: ipsec up net-net ipsec up proto1 ipsec up proto2 The connection host-host is not instantiated because auto=add is missing and the default auto=ignore is assumed. If this is true, then the CHILD_SAs created at this stage (after the first ipsec up) cover all protocols between specified subnets (because proto1 proto2 are not started). Then, when proto1 and proto2 are started the traffic is narrowed down to specified protocols (via a rekeying of CHILD_SAs??). Do you confirm? Actually I chose different subnets 10.5.0.0/16 and 10.6.0.0/16 for connections proto1 and proto2. But if the same subnets would be used for proto1, proto2, and net-net, then http traffic would used the IPsec SAs set up by proto1, smtp traffic the IPsec SAs set up by proto2, and the remaining traffic would use the IPsec SAs set up by net-net. If this is confirmed, then IPsec-ed traffic depends, when using 'also=', on the order of calling ipsec up and requires that both ends of the tunnel to start-up connections on the same order. As you can see from the example above, the order does not matter. The kernel always ties to achieve a closest match between payload traffic and the existing IPsec policies. Best Regards Mugur Kind regards Andreas == 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
[strongSwan] Several TS on a same connection
Hello, I looked to strongSwan connection parameters (http://wiki.strongswan.org/wiki/1/ConnSection) and I am not sure how to define several tunnels between the same endpoints, each tunnel with several traffic selectors. In my understanding an independent tunnel is defined by a conn name directive with the condition that its body does not contain an also = section name directive. Now, I want, for each tunnel to include several traffic selectors; i.e. several left|rightprotoport = protocol/port and several left|rightsubnet = ip subnet. Moreover I want to combine traffic selectors in a specific way for a same connection. For example to specify somehow leftprotoport=icmp ONLY for leftsubnet= 192.168.10.0/24 and leftprotoport=UDP ONLY for leftsubnet= 172.16.10.0/24 Can you please specify which are all possibilities of using the IKEv2 extended traffic selector concept with strongSwan. Thank you Mugur ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Several TS on a same connection
Hello Andreas, Thank you for your help. From your answer I conclude that between two peers at most one IKE_SA (= at most one IPsec tunnel) can be created regardless how multiple conn directives are specified (with or without %default or 'also='). I don't really understand the asymmetry of values for leftprotoport=tcp and rightprotoportin=tcp/http in your example. My understanding of the example is that all tcp packets from local (=left) to remote (=right) are tunneled but only http packets from remote to local are tunneled. Is my assumption correct? In this case which data flows (subnets and protos) are exactly protected by the first CHILD_SA and which by the second CHILD_SA? Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: samedi 26 décembre 2009 14:48 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Several TS on a same connection Hello Mugur, it does not matter if you define each tunnel between two peers independently or if you use conn %default or an also= construct to save typing work. All tunnels, i.e. a definition of traffic selectors are grouped under the same IKE_SA which is going to be established between the two peers. The IKEv2 charon daemon allows the enumeration of several traffic selectors for the same CHILD_SA using left|rightsubnet: leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 will establish the following four IPsec SAs with a single CHILD_SA: 10.1.0.0/16 - 10.2.0.0/16 10.1.0.0/16 - 10.4.0.0/16 10.3.0.0/16 - 10.2.0.0/16 10.3.0.0/16 - 10.4.0.0/16 Currently traffic selectors with protocol/port restrictions using the left|rightprotoport parameters cannot be grouped together in a single CHILD_SA. You will have to define a separate conn description for each protocol/port combination resulting in a separate CHILD_SA exchange. Thus the example conn net-net also=host-host leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 auto=start conn proto1 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.5.0.0/16 leftprotoport=tcp rightprotoport=tcp/http auto=start conn proto2 also=host-host leftsubnet=10.5.0.0/16 rightsubnet=10.5.0.0/16 leftprotoport=tcp rightprotoport=tcp/smtp auto=start conn host-host left=IP address of left right=IP address of right would create six IPsec SAs between left and right, using a primary IKE_AUTH and two additional CHILD_SA exchanges. Best regards Andreas ABULIUS, MUGUR (MUGUR) wrote: Hello, I looked to strongSwan connection parameters (http://wiki.strongswan.org/wiki/1/ConnSection) and I am not sure how to define several tunnels between the same endpoints, each tunnel with several traffic selectors. In my understanding an independent tunnel is defined by a conn name directive with the condition that its body does not contain an also = section name directive. Now, I want, for each tunnel to include several traffic selectors; i.e. several left|rightprotoport = protocol/port and several left|rightsubnet = ip subnet. Moreover I want to combine traffic selectors in a specific way for a same connection. For example to specify somehow leftprotoport=icmp ONLY for leftsubnet= 192.168.10.0/24 and leftprotoport=UDP ONLY for leftsubnet= 172.16.10.0/24 Can you please specify which are all possibilities of using the IKEv2 extended traffic selector concept with strongSwan. Thank you 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
Re: [strongSwan] Several TS on a same connection
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 -Original Message- From: ABULIUS, MUGUR (MUGUR) Sent: samedi 26 décembre 2009 18:22 To: Andreas Steffen Cc: users@lists.strongswan.org; Pisano, Stephen G (Stephen); ROSSI, MICHEL MR (MICHEL); SCARAZZINI, FABRICE (FABRICE); ABULIUS, MUGUR (MUGUR) Subject: RE: [strongSwan] Several TS on a same connection Andreas, Thank you again for responding. Indeed, the explanation concerning asymmetry for leftprotoport= and rightprotoportin= is quite simple. Do you confirm that calling: ipsec up net-net on the 'net-net' connection from your example will create IPsec SAs only corresponding to conn net-net and to conn host-host (because specified by also=host-host), but connections conn proto1 and conn proto2 are not started yet? If this is true, then the CHILD_SAs created at this stage (after the first ipsec up) cover all protocols between specified subnets (because proto1 proto2 are not started). Then, when proto1 and proto2 are started the traffic is narrowed down to specified protocols (via a rekeying of CHILD_SAs??). Do you confirm? If this is confirmed, then IPsec-ed traffic depends, when using 'also=', on the order of calling ipsec up and requires that both ends of the tunnel to start-up connections on the same order. Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: samedi 26 décembre 2009 17:31 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org; Pisano, Stephen G (Stephen); ROSSI, MICHEL MR (MICHEL) Subject: Re: [strongSwan] Several TS on a same connection ABULIUS, MUGUR (MUGUR) wrote: Hello Andreas, Thank you for your help. From your answer I conclude that between two peers at most one IKE_SA (= at most one IPsec tunnel) can be created regardless how multiple conn directives are specified (with or without %default or 'also='). Yes, this is true. But you can execute e.g. ipsec up net-net several times and multiple IPsec SAs for the same traffic selectors are created. Usually only the last-created SA is actually used for traffic, though. On of our pending projects intends to create multiple tunnels for different QoS classes but this would require some fundamental changes in the Linux kernel. I don't really understand the asymmetry of values for leftprotoport=tcp and rightprotoportin=tcp/http in your example. My understanding of the example is that all tcp packets from local (=left) to remote (=right) are tunneled but only http packets from remote to local are tunneled. Is my assumption correct? The explanation is quite simple: If an application wants to reach a service under a well-known port (e.g. 80 for http or 25 for smtp) then the source port will be an arbitrary higher port which we cannot predict. Therefore we include all possible TCP or UDP ports since port range restrictions are not currently supported by the Linux kernel. In this case which data flows (subnets and protos) are exactly protected by the first CHILD_SA and which by the second CHILD_SA? The first CHILD_SA would set up the IPsec SA for the following policy: 10.5.0.0/16[tcp/0] .. 10.6.0.0/16[tcp/http] and the second: 10.5.0.0/16[tcp/0] .. 10.6.0.0/16[tcp/smtp] Actually there was a copy-and-paste error in my previous email. rightsubnet was supposed to be 10.6.0.0/16. Best regards Andreas Best Regards Mugur -Original Message- From: Andreas Steffen [mailto:andreas.stef...@strongswan.org] Sent: samedi 26 décembre 2009 14:48 To: ABULIUS, MUGUR (MUGUR) Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Several TS on a same connection Hello Mugur, it does not matter if you define each tunnel between two peers independently or if you use conn %default or an also= construct to save typing work. All tunnels, i.e. a definition of traffic selectors are grouped under the same IKE_SA which is going to be established between the two peers. The IKEv2 charon daemon allows the enumeration of several traffic selectors for the same CHILD_SA using left|rightsubnet: leftsubnet=10.1.0.0/16,10.3.0.0/16 rightsubnet=10.2.0.0/16,10.4.0.0/16 will establish the following four IPsec SAs with a single CHILD_SA: 10.1.0.0/16 - 10.2.0.0/16 10.1.0.0/16 - 10.4.0.0/16 10.3.0.0/16 - 10.2.0.0/16 10.3.0.0/16 - 10.4.0.0/16
Re: [strongSwan] Several TS on a same connection
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
