On Mar 14, 2012, at 8:00 AM, Tero Kivinen wrote: > 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.
Users use passwords, but endpoints can use PSKs and certificates. PSKs should be pairwise, so they have to be provisioned dynamically. It's all part of having to create the PAD entries dynamically. If we anyway have to provision peer's IP address/locator and identity (DN, username) we might as well also provision a PSK. If we really want to authenticate users, we need to use EAP to authenticate to some trusted (by whom?) server. Then we can extend that authentication to other endpoints and gateways that are not connected to the same AAA server, perhaps using some mechanism like tickets or session resumption or ERP, or by having the gateway provision the shared secrets for the client and the other peers. > This means that we might need to add creation of temporary credentials > to the protocol. I think that unless we are going to mandate a system based solely on certificates, that's a given. > 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. Take a company the size of IBM. They have 400,000 employees. Probably hundreds of thousands of smartphones, hundreds of thousands of PCs, and thousands of VPN gateways. It doesn't make sense that each smartphone holds the entire PAD for all this, and we haven't even mentioned partners and customers yet. You could keep a kind of star topology, where the phones are secondary nodes, and they connect to some primary nodes (using IKE or something else). When they need to connect to some other primary or secondary node, they get that information from the primary node. And you can have the primary nodes know everything, or make it hierarchical or DNS-based or something else entirely. This discovery mechanism is a big part of the charter item, and I think it should avoid having to push the entire policy to each endpoint. > 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. That's a matter of policy. Sometimes they want to inspect traffic going in and out of their organizational VPN, but not traffic flowing within it. So traffic from the Maastricht office can flow freely to the Quebec City office, and doesn't have to go through the New York datacenter. But traffic going to Facebook needs to be scanned, and goes through the datacenter. > 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. I think the point of section 3.2 is that stars are defined partly because they're easier (just one credential to configure on each satellite). The challenge is to overcome the difficulty in defining a mesh. > > 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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
