Yoav Nir writes: > 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.
I think this is something that should be pointed out in the use case for endpoint to endpoint scenario. Just to make it clear. Also adding note about that to the security considerations section is also needed. > 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. I would actually think short lived certificates would be better and much more scalable way to provide temporary credentials. > > 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 most of those big enterprices they already have some kind of tools to push policy and configuration to every single device. They might not even allow device to connect to the network before they can verify that the device has up to date configuration and policy. As far as I understand this is already standard working practices they are doing now, and claiming you cannot do that is bit misleading. But as I sid they do require some out of band policy distribution mechanisms which are not standardized... > > 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. Yes, and I think the star topology section should point out that in some cases the topology is required because of the policy reason, as this do affect our scope / use cases. > > 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. I think that paragraph should then be modified to say that... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
