Project

General

Profile

Issue #2160

support for opportunistic encryption

Added by Noel Kuntze over 2 years ago. Updated over 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.5.1
Resolution:

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?

Also available in: Atom PDF