Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Scott C Moonen writes: Tero, I am not comfortable with the following statement: . . . thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses . . . I would prefer that the server re-map the TS values back to IP1 and IPN2 when sending its response. This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. This is consistent with the general expectation that the response's TS payloads are a subset of the request's payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. The client does not absolutely need this information (it would perhaps help for deterministic checksum fixup, however in transport mode as long as an integrity algorithm is used the checksum provides no additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. I think it is also advantageous to contain this fixup processing to one code path (processing TS payloads in received requests), and it also simplifies the response message processing (the client does not need to complicate its checks to verify that the response's TS payloads are a subset of the request's). This separation of responsibility is more advantageous to a client implementation that needs to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). Finally, what I propose above is how our own IKEv1 implementation works in cases where ID payloads are sent for transport mode. :) As a responder we found it best to bend over backwards to cater to the initiator's view of the world. In IKEv1 there is separate payloads for sending the original addresses. In IKEv2 we do not have that, thus we must use traffic selectors for that. I'm also concerned about the following statement: After this it does SPD lookup based on those new traffic selectors. . . . If entry is found but it does not allow transport mode, then MUST undo the address substitution and redo the SPD lookup using the original traffic selectors. . . . This statement is incoherent to me. From the fact that the initiator proposed transport mode, it is clear that the initiator identifies TSi with itself and TSr with the server. No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full choice of ignoring it and using tunnel mode instead. TSi and TSr do NOT identify initiator at all, initiator is already identified by the ID payloads. TSi and TSr are used to select suitable SPD entry for the given identified initiator. As for transport-mode NAT-T case the original TSi and TSr can be quite unknown for the responder, we first try with the converted addresses, but if we need to fall back to tunnel-mode NAT-T, then we want to keep original traffic selectors as now the packets exiting from the tunnel will have those addresses (i.e. packets coming from the tunnel will have IP1 and IPN2 as their source and destination addresses, as NAT in the middle does not substitute them). The address substitution exactly translates these addresses into the domain of the responder's SPD. If the responder's policy indicates that transport mode is not acceptable for this SPD entry, then I think the only possible outcome is that SA negotiation should be failed. No other SPD entry could possibly match the initiator's intentions. Initiator asked that if possible use transport mode with these addresses, if transport mode is not possible then use tunnel mode. Even if transport mode was not allowed, it is possible that responder do have tunnel mode rule that is allowed for that client even when transport mode was not. I do not see how you can claim that No other SPD entry could not be found, as initiator only gave hint that it would like to use transport mode. The use of tunnel vs transport mode is fully based on the responders policy. However, the MUST quoted above causes the responder to treat these addresses in an incoherent way: 1) The responder has detected a NAT in front of the initiator, so treating IP1 as being within the domain of the
Re: [IPsec] #107: Sending certificate chains in IKEv2
All of which taken together indicates the Sec. 3.6 needs to be rewritten. It'll be hard enough to get interoperability with all these options, but certainly if much remains undocumented. We might even need to resort to defining what the mythical minimal implementation is allowed to do. Thanks, Yaron -Original Message- From: Tero Kivinen [mailto:kivi...@iki.fi] Sent: Thursday, August 27, 2009 9:57 To: David Wierbowski Cc: ipsec@ietf.org; ipsec-boun...@ietf.org; Yaron Sheffer Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2 David Wierbowski writes: I agree with Tero that Yoav's proposed text adds clarity and effectively it does not add a new MUST; however, to address Paul's concern can we just change the words MUST be to the word are or lower case should be? For example: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload. This text looks good for me. And I think it is important to add this to X.509 Certificate - Signature (4) case, even when we have some generic text elsewhere saying same thing, as this is the most common case people are using now. As Tero points out, this is the only way to send a chain this using X.509 Certificate - Signature.encoding. MUST terminology really is not needed in my opinion. Agreed. I think in addition to that text we might want to add some generic text to the final paragraph saying: Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). In case those formats which contain one certificate are used and multiple certificates are to be sent then each certificate are sent as separate Certificate Payload. Or add similar text than what is in the 3.7 Certificate Request Payload which have following sentence at the end of first paragraph If multiple CAs are trusted and the certificate encoding does not allow a list, then multiple Certificate Request payloads would need to be transmitted. One more thing, do we want to explictly mention that it is very common to mix multiple types of certificate payloads, i.e. send certificate multiple payloads some having X.509 Certificate - Signature (4) format and some having Certificate Revocation List (7) format. Another combination could be Raw RSA Key (11) and X.509 Certificate - Signature (4). In that case the Raw RSA Key (11) format is meant for minimal implementations who have the raw RSA key of the other end statically configured to their policy, and the X.509 Certificate - Signature (4) format is meant for full implementations which can process and validate certificates. Note also that not all certificates are there to form a chain, they can also provide other things like CRLs or even multiple different chains towards the different CAs (in case the private/public key use has certificates from multiple CAs, and other end didn't indicate any known CA), so the extra certificate payloads (after the first one used to sign the AUTH payload) are there just to help validation of the first certificate, not necessarely to form a chain. -- kivi...@iki.fi Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is...), so we shouldn't do it unless we're quite sure. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
I'll second that. Yaron _ From: pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com] Sent: Thursday, August 27, 2009 14:06 To: Yaron Sheffer; ipsec@ietf.org Subject: RE: #79: Remove CP from Create_Child_SA? I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav's proposal. This would be a protocol change (even if we don't understand what the current semantics is.), so we shouldn't do it unless we're quite sure. Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
I disagree. Payloads in a particular CREATE_CHILD_SA exchange should be specifically related to the SA being created. The IKE_AUTH exchange is different, because it is used to set up everything we need to get an IPsec SA going. We do not use the CREATE_CHILD_SA to delete old SAs, to query application versions or to advertise capabilities through notifications or Vendor IDs, so it should also not include IP address maintenance. That's what INFORMATIONAL exchanges are for. On Aug 27, 2009, at 2:05 PM, pasi.ero...@nokia.commailto:pasi.ero...@nokia.com pasi.ero...@nokia.commailto:pasi.ero...@nokia.com wrote: I would repeat my comment from April: http://www.ietf.org/mail-archive/web/ipsec/current/msg04245.html If we continue to allow CP in INFORMATIONAL exchange (and IMHO we should), it should be allowed in CREATE_CHILD_SA, too (with exactly same semantics). Best regards, Pasi From: ipsec-boun...@ietf.orgmailto:ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Yaron Sheffer Sent: 26 August, 2009 00:23 To: ipsec@ietf.orgmailto:ipsec@ietf.org Subject: [IPsec] #79: Remove CP from Create_Child_SA? Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306, section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. Everyone, please comment on the above, even if you support Yoav’s proposal. This would be a protocol change (even if we don’t understand what the current semantics is…), so we shouldn’t do it unless we’re quite sure. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.orgmailto:IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #107: Sending certificate chains in IKEv2
David Wierbowski writes: I agree with Tero that Yoav's proposed text adds clarity and effectively it does not add a new MUST; however, to address Paul's concern can we just change the words MUST be to the word are or lower case should be? For example: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload. This text looks good for me. And I think it is important to add this to X.509 Certificate - Signature (4) case, even when we have some generic text elsewhere saying same thing, as this is the most common case people are using now. As Tero points out, this is the only way to send a chain this using X.509 Certificate - Signature.encoding. MUST terminology really is not needed in my opinion. Agreed. I think in addition to that text we might want to add some generic text to the final paragraph saying: Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). In case those formats which contain one certificate are used and multiple certificates are to be sent then each certificate are sent as separate Certificate Payload. I agree that text like this should be added. I suggest some minor editorial changes (change In case those formats to When and are to is: Some of the certificate formats can only contain one certificate (for example formats 4, 7, 11 and 12), and some can contain multiple certificates (for example 1, 13). When formats which contain one certificate are used and multiple certificates are to be sent then each certificate is sent as separate Certificate Payload. In that past I've asked if the first certificate payload is encoded using type 13 does the first certificate in the bundle have to be the one used to create the signature and you've answered yes. Perhaps we should also clarify that here. I do not think we can make such a statement when type 1 is used. I know of at least one vendor that uses type 1. The signing cert is not the first certificate in their PKCS #7 data. Or add similar text than what is in the 3.7 Certificate Request Payload which have following sentence at the end of first paragraph If multiple CAs are trusted and the certificate encoding does not allow a list, then multiple Certificate Request payloads would need to be transmitted. I prefer your previous wording. One more thing, do we want to explictly mention that it is very common to mix multiple types of certificate payloads, i.e. send certificate multiple payloads some having X.509 Certificate - Signature (4) format and some having Certificate Revocation List (7) format. I agree that we should state that mixing multiple types of certificate payloads is allowed. The examples are helpful, but I'm not sure we need to include them in the text. Another combination could be Raw RSA Key (11) and X.509 Certificate - Signature (4). In that case the Raw RSA Key (11) format is meant for minimal implementations who have the raw RSA key of the other end statically configured to their policy, and the X.509 Certificate - Signature (4) format is meant for full implementations which can process and validate certificates. Note also that not all certificates are there to form a chain, they can also provide other things like CRLs or even multiple different chains towards the different CAs (in case the private/public key use has certificates from multiple CAs, and other end didn't indicate any known CA), so the extra certificate payloads (after the first one used to sign the AUTH payload) are there just to help validation of the first certificate, not necessarely to form a chain. I agree that we should stste the extra certificate payloads are there to help validation of the first certificate, not necessarely to form a single chain. -- kivi...@iki.fi___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554)
On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen kivi...@iki.fi wrote: Bhaskar Dutta writes: Does any IPSec implementation support RFC 3554 (On the Use of Stream Control Transmission Protocol (SCTP) with IPsec)? Yes. Altough I do not know if it has been really tested (mostly just using sctp_test and single pair of ip-addresses). I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming unless RFC 3554 is supported I will need to configure 2 * n * m Security Associations. With IKEv2 you should just create one SA having multiple source and destination addresses. Then if more addresses are later added you need to create new SA with all of the addresses (or just new addresses). -- kivi...@iki.fi Thanks a lot! I looked up for examples on setting up sainfo entries in racoon's remote.conf with multiple source/destination addresses but the man pages or searching the web did not lead to anything. Couldnt even find any examples with multiple entries in sainfo. Do you have any idea on how to write the sainfo entries in remote.conf and spdadd entries in setkey.conf that will work with multiple source/dest addresses? I did write to the ipsec-tools-users list but no luck yet. Thanks, Bhaskar ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554)
Hi Bhasker, This document will help you: http://www.ipsec-howto.org/ipsec-howto.pdf *It has sample configs for racoon. *Thanks Regards, Raj On Thu, Aug 27, 2009 at 6:53 PM, Bhaskar Dutta bhas...@gmail.com wrote: On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen kivi...@iki.fi wrote: Bhaskar Dutta writes: Does any IPSec implementation support RFC 3554 (On the Use of Stream Control Transmission Protocol (SCTP) with IPsec)? Yes. Altough I do not know if it has been really tested (mostly just using sctp_test and single pair of ip-addresses). I am working on SCTP over IPSec (linux 2.6.27) and in case of multihoming unless RFC 3554 is supported I will need to configure 2 * n * m Security Associations. With IKEv2 you should just create one SA having multiple source and destination addresses. Then if more addresses are later added you need to create new SA with all of the addresses (or just new addresses). -- kivi...@iki.fi Thanks a lot! I looked up for examples on setting up sainfo entries in racoon's remote.conf with multiple source/destination addresses but the man pages or searching the web did not lead to anything. Couldnt even find any examples with multiple entries in sainfo. Do you have any idea on how to write the sainfo entries in remote.conf and spdadd entries in setkey.conf that will work with multiple source/dest addresses? I did write to the ipsec-tools-users list but no luck yet. Thanks, Bhaskar ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #79: Remove CP from Create_Child_SA?
Yoav Nir wrote: I disagree. Payloads in a particular CREATE_CHILD_SA exchange should be specifically related to the SA being created. The IKE_AUTH exchange is different, because it is used to set up everything we need to get an IPsec SA going. If we were designing IKEv2 from scratch, I would agree with you. But we're not, so we're not discussing what would be the best design here, but rather whether this part of RFC 4306 is so horribly broken it absolutely needs to be changed (RFC 4306 is unambiguous that CPs are allowed in CREATE_CHILD_SA exchange). I think it's not broken, just somewhat ugly and inelegant... Best regards, Pasi (not wearing any hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Tero, in short: 1) I still prefer to echo back TS payloads as I described. I realize that the TS payloads are the only opportunity that IKEv2 has to reproduce the effect of IKEv1's NAT-OA payloads. But using the traffic selectors in this way -- and only if the responder ends up agreeing to transport mode! -- still strikes me aesthetically as quite jarring, which is certainly a subjective thing but not a meaningless thing. :) As I indicated, I'm not worried about being unable to deterministically fixup the checksums because in transport mode with integrity protection, checksums aren't critical. I'm interested to hear what other implementers think. 2) I think we have a fundamental disagreement about whether it is proper for addresses in foreign networks to be configured in the SPD. Our own IKEv1 NAT-T implementation has made some (I think reasonable) design assumptions that exclude this, even in NAT-T tunnel mode. So, briefly, the MUST as you have written it is not even possible for our implementation to satisfy, because by definition our SPD cannot contain addresses from foreign networks. As you might guess, our assumptions lead to certain implications (such as the fact that we need to do various IP header address fixup and also port translation). I'm not sure it's worth boring the list with all the details. Perhaps what I can do is put together a note over the next couple of days to privately discuss our implementation with you. I'd mainly like to make sure that if there is a MUST here, it is written in such a way that implementations such as ours are not broken by definition. 3) I agree with you about my suggested replacement text, MUST fail the SA negotiation. Because of the way that USE_TRANSPORT_MODE is negotiated, what I propose is not correct. For our own implementation, the correct behavior would be to accept the proposed SA without use of transport mode. At the moment I'm not sure how best to word this MUST to accommodate implementations that do and do not allow foreign network addresses in the SPD. Thanks, Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen kivi...@iki.fi To: Scott C Moonen/Raleigh/i...@ibmus Cc: ipsec@ietf.org ipsec@ietf.org, ipsec-boun...@ietf.org Date: 08/27/2009 04:15 AM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Scott C Moonen writes: Tero, I am not comfortable with the following statement: . . . thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses . . . I would prefer that the server re-map the TS values back to IP1 and IPN2 when sending its response. This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. This is consistent with the general expectation that the response's TS payloads are a subset of the request's payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. The client does not absolutely need this information (it would perhaps help for deterministic checksum fixup, however in transport mode as long as an integrity algorithm is used the checksum provides no additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. I think it is also advantageous to contain this fixup processing to one code path (processing TS payloads in received requests), and it also simplifies the response message processing (the client does not need to complicate its checks to verify that the response's TS payloads are a subset of the request's). This separation of responsibility is more advantageous to a client implementation that needs to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). Finally, what I propose above is how our own IKEv1 implementation works in cases where ID payloads are sent for transport mode. :) As a responder we found it best to bend over backwards to cater to the initiator's view of the world. In IKEv1 there is
Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554)
On Thu, Aug 27, 2009 at 10:36 PM, Raj Singhrsjen...@gmail.com wrote: Hi Bhasker, This document will help you: http://www.ipsec-howto.org/ipsec-howto.pdf It has sample configs for racoon. Thanks Regards, Raj Hi Raj, I'd already gone through this howto as well as several others. I couldn't find _anything_ that contains configuration examples for specifying multiple addresses in a single SA (which is the requirement for SCTP over IPSec RFC). As Tero pointed out, the support is there, but he doubts if any real testing has been done. Once I figure out how to specify the configuration with ipsec-tools I am planning to test it out thoroughly. Thanks, Bhaskar ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
