Hi Yoav,
I like your attempt at reducing the requirement set to the minimum.
Parts of the text I think do not distinguish well between IPsec hosts
(such as remote access clients) and (simple) hosts, that are non-IPsec
hosts protected behind a gateway. Presumably simple hosts will be
unaffected by this protocol.
And in the spirit of minimizing the set of requirements: isn't your #3
solution components just an optimization? I think in many cases a
protocol that includes #1 and #2 but not #3 could be sufficient for
scale. And then #3 could be added as an extension. Or we can decide that
we do not need a fully general #3, and we're good enough with simple
shortcuts between two spokes of the same hub.
Thanks,
Yaron
On 03/16/2014 08:25 AM, Yoav Nir wrote:
As promised, here's my view of what a short list of requirements for AD-VPN
should be like.
First, a few terms:
An AD-VPN is a subset of the hosts on the Internet, such that all traffic between two
nodes within the AD-VPN must be protected by IPsec when it traverses nodes outside of the
AD-VPN. An IPsec gateway is a node within the AD-VPN that protects the traffic for
passage across nodes outside of the AD-VPN. An IPsec host is a node that protects only
its own traffic (common for remote access VPNs). The set of hosts whose traffic is
protected by an IPsec gateway is called its "protected domain". The AD-VPN can
be said to be partitioned into protected domains.
All this can be accomplished with IPsec and IKEv2 as defined in RFCs 4301,
4303, and 5996. What's missing is dynamic updates to SPD and PAD, and a way to
deal with the complexity of the configuration of large scale VPNs.
So any IPsec gateway or host joining an AD-VPN has to know several things:
- the total AD-VPN. Specifically, whether an IP address (could the the
destination of an outgoing packet or the source of an incoming packet) is or is
not in the AD-VPN. Packets that are destined to outside the AD-VPN can be sent
in the clear over the Internet.
- For each host in the AD-VPN, a next-hop gateway.
- Credentials for connecting to such a next-hop gateway.
- If more protected domains, gateways or hosts are added to the AD-VPN, we
want the node to learn of this. This doesn't have to happen immediately, but we
would like to be able to set an upper bound on how long it takes.
For a simple configuration, there can be one such next-hop gateway for all
addresses (that's a hub). Using a single hub for all the VPN is not efficient,
so even if we accept this as an initial configuration, we need this to expand.
Another requirement of this protocol is to limit the impact of rogue or
compromised nodes. Specifically, such nodes should not be able to alter the
AD-VPN by dynamically removing parts of the protected domains of other
gateways, and checks and limits should be imposed on their ability to claim
parts of the Internet as part of their own protected domains. This requirement
may have a negative impact on usability, for example if additions to the AD-VPN
would require matching configuration on both the protecting gateway and on some
other node (could be a part of the AD-VPN, like a hub node, or an external
server, or maybe an RPKI CA), but we believe it is essential for security in
the face of the possibility of compromised nodes.
So to get all this, we need the following from the solution protocol (and it
could be one protocol, or a whole suite of protocols at different levels:
1. A protocol for discovery of the AD-VPN, and at least one next-hop gateway
with the credentials to access it. The latter part may be assumed to be
manually configured, but the discovery has to be automatic, as the total AD-VPN
is assumed to change. Note that the other side of this protocol is not required
to be part of the AD-VPN. A server giving out this information over HTTPS is an
acceptable solution, as is encoding this information in the DNS.
2. A protocol for propagating changes to the AD-VPN throughout the network.
This does not have to be a single protocol. For example, We could have hub
spokes that communicate this information through routing protocols, and spoke
nodes that get the information from the hub nodes. Or trusted nodes that update
an HTTPS server, while the other nodes periodically download said information.
The requirement is that eventually, and after a bounded time period, all nodes
will know of the change.
3. A protocol for discovery of more efficient paths through the AD-VPN.
Specifically, such a protocol would allow an IPsec gateway (or an IPsec host)
to create a new tunnel such that the traffic would require fewer hops on its
way to the destination host. This protocol would also need to handle providing
credentials to the nodes. It's not enough to tell a gateway to set up a tunnel
with another gateway at address 192.0.2.5, You also need to tell what
credential that gateway is going to present (by DN or alternate name, and maybe
by public key as in DANE) and also what IDi/IDr are going to be used in IKE.
These are the requirements as I see them. The opinions posted here are my own,
they do not reflect those of my employer, and do not necessarily reflect those
of my co-authors on the AD-VPN draft.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
