A couple of remarks (with no hats)
If we’re bikeshedding the names, I think the difference is that in one case the
two NSFs generate traffic keys between themselves, and in the other it is the
controller that generates the keys for them. So how about “distributed keying”
vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.
Also, I have been asked by someone not on this list whether our work covers the
road warrior use case. I said it didn’t and wondered why. So I got these points:
Road warriors are numerous and not where the administrator can configure them
manually.
Additionally, the configuration of what networks, gateways (NSFs), and
resources a road warrior may access (in IPsec terms, the SPD and PAD) change
often.
Because of the above, some automatic method of configuring SPD and PAD is
needed.
There is also the issue of multiple VPN gateways covering similar domains, and
VPN gateways being overloaded or down for maintenance, as well as malfunctions
in the network behind those VPN gateways. So the decision on which gateway a
road warrior should use to access a particular resource is also a natural
question to ask an SDN controller.
Since I used to work for a VPN vendor, I can tell you what our product did:
The current configuration was formatted (automatically by a management
function) as a text file that the road warrior downloaded through the VPN
gateway (the gateway doubled as a server serving this one file)
The proper gateway to connect to was determined by pinging all gateways that
were possible according to the configuration file.
This did not account for any internal networking issues.
I don’t know if this should be part of *this* effort, but there is a use case
for road warrior SDN.
Yoav
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
