For key management you might want to refer them to the old but still
useful RFC 4107 <https://www.rfc-editor.org/rfc/rfc4107.txt>.
Thanks,
Yaron
On 18/07/17 10:45, Yoav Nir wrote:
We’re going to have a screaming match tomorrow at TLS about forward
secrecy.
You don’t have forward secrecy if the session keys were generated by a
third party. You’re replacing IKE with a three-party system.
But I am more worried about the second issue. I’m not sure SDN is the
right model for configuring IPsec.
Yoav
On 18 Jul 2017, at 10:34, Paul Wouters <[email protected]
<mailto:[email protected]>> wrote:
ACE on Monday also mentioned this "SPDs without IKE" option. I
expressed my concern that they believe IKE is only about sharing SPDs
and keys and warned them against things like devices without
batteries restarting and getting the same values and end up re-using
the same counter for AEAD algorithms.
Sent from my iPhone
On Jul 18, 2017, at 10:29, Yoav Nir <[email protected]
<mailto:[email protected]>> wrote:
Hi.
This may be of interest to this working group.
The I2NSF working group is meeting this afternoon at 13:30
On the agenda ([1]) there’s a 10-minute slot for controlling IPsec
endpoints using SDN ([2]).
I think this draft has two issues:
1. Their IKE-less case (case #2) has session keys generated on the
controller and forwarded to the IPsec endpoints. IMO this
introduces new ways for the keys to leak.
2. The information flow in the draft is all from the controller to
the endpoints. The controller is assumed to a-priori know the
entire topology of all endpoints. IMO this is not realistic for
VPNs where often the addresses are allocated by third party ISPs.
I think any SDN or SDN-like solution for populating the SPD and PAD
would need to have information flowing from the endpoints to the
controller about the protected domain of that endpoint. Before that
you can’t generate the SPDs.
OTOH this group failed in creating something like that in the AD-VPN
work item. Several companies are now offering their own “SD-WAN”
solution that is partly about automatic configuration of IPsec tunnels.
So in case you’re interested, you can come to the I2NSF meeting and
hear their presentation.
Yoav
[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt
[2]
https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03
_______________________________________________
IPsec mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
