In section 2.1 where there is dicsussion about the endpoint to endpoint vpn use case, it should be noted, that this might require different temporary credentials. Endpoints (especially remote access users) do use passwords or similar credentials which cannot be forwarded. I.e. if the shared secret is used to authenticate the end node to the gateway, that same shared secret cannot be given to the another end point as that would allow it to impersonate the first peer. Also the endpoint most likely cannot access the same AAA server than what security gateway does, so if peer uses EAP to authenticate itself to the security gateway, the endpoint to endpoint vpn cannot use the same credentials.
This means that we might need to add creation of temporary credentials to the protocol. In section 3.1 exhaustive configuration I think it is incorrect to claim it does not scale, as if the configuration is pushed to all devices using some kind of out of band configuration tool it is completely possible to make extreamly large setups. Dynamic updates do cause some problems there, as every change might require policy to be pushed to every single node. I think the main problem with this setup is that it requires that out of band configuration system, and those are proprietary which means you cannot use implementations from different vendors. In section 3.2 about star topology it should be noted, that quite often adminstrators do require star topology because they want to do some kind of inspection for all traffic inside the vpn. This kind of policy might make it impossible to do endpoint to endpoint connections, and might limit which kind of gateway to gateway cases are allowed. I do not see how the last paragraph in section 3.2 does not seem to belong there: The challenge is how to build large scale, fully meshed IPsec protected networks that can dynamically change with minimum administrative overhead. The section 3.2 talks about existing star topology solutions, and making large scale fully meshed network is not even in scope for such systems. In section 3.2 we should also mention that with proprietary approaches it is not clear whether they implement all checks required by the IPsec architecture, i.e tunnel exit checks, firewall rules, security policy checks etc. They might do those, or they might skip them... In general the current use case description was quite good, and I think this document is good start. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec