Issue #2160
support for opportunistic encryption
Description
Does strongSwan actually support opportunistic encryption after the trap-any branch was merged?
This test scenario doesn't talk about opportunistic
encryption, so I guess it enforces IPsec protection for the hosts listed in rightsubnet. Is that right?
For real opportunistic encryption, I guess charon needs to insert pass policies for host that don't support
OE or where auth fails. So far correct?
History
#1 Updated by Tobias Brunner over 2 years ago
- Status changed from New to Feedback
Does strongSwan actually support opportunistic encryption after the trap-any branch was merged?
No.
This test scenario doesn't talk about opportunistic
encryption, so I guess it enforces IPsec protection for the hosts listed in rightsubnet. Is that right?
Correct.
For real opportunistic encryption, I guess charon needs to insert pass policies for host that don't support
OE or where auth fails. So far correct?
I guess, but OE can go even further (no authentication, authentication via DNSSEC etc.). You might want to read some of the related RFCs (e.g. the old RFC 4322, or RFC 7619 that allows negotiation IKEv2 SAs without authentication).
#2 Updated by Noel Kuntze over 2 years ago
Tobias Brunner wrote:
For real opportunistic encryption, I guess charon needs to insert pass policies for host that don't support
OE or where auth fails. So far correct?I guess, but OE can go even further (no authentication, authentication via DNSSEC etc.). You might want to read some of the related RFCs (e.g. the old RFC 4322, or RFC 7619 that allows negotiation IKEv2 SAs without authentication).
Thank you for the links. Would a patch set for OE in strongSwan be acceptable?