On 6/12/13 8:05 PM, Paul Wouters wrote:
They're not supposed to. They are supposed to increase efficiency and reliability. The problem we're trying to solve is that the way the standards and products work today, tunnels are configured one at a time. It's so labor-intensive, that administrators minimize the number of tunnels be defining hub-and-spoke topologies for any VPN that is large enough.We have agreed-upon requirements [1].I was unfortunately not really active during the requirements phase. While I believe there is a need for auto-discovery withoutpreconfiguration, I do not think the current ideas of merging site-to-site based VPNs using ADVPN proposals really increases security.
There is another problem that stems from the same state of standards and products - that IPsec is hardly ever used between administrative domains. Solving that would be great, and opportunistic encryption might be a start. Something with RPKI certificates could make it even better. But that is not the focus of this effort.
It seems a compromise for convenience at the expense of the intended security of IPsec, and a continued trend from strict policy range based VPNs to loose routing based VPNs, reducing IPsec to a virtual private untrusted ethernet cable.
I don't disagree, but defining the tunnels one at a time sounds more like SNA than TCP/IP.
Yoav
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
