Re: [IPsec] My view of the requirements from AD-VPN

[Yaron Sheffer <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>