On Nov 17, 2011, at 2:17 AM, Michael Richardson wrote: > > Mike> I am not sure where you are getting a set of extended > Mike> access-lists. There aren't any extended access-lists added. > Mike> If a packet is routed through the tunnel it is encapsulated > Mike> and then encrypted. There isn't any access-list necessary. > > Oh, I'm sorry, I thought you were creating a secure network! > > What you are saying is that you are creating an overlay network, where > different sites can impersonate each other!
Not necessarily. If your device drops packets that come through the "wrong" tunnel, you're safe. Typically in a complex network you will allow multiple paths through the overlay network, and then some spoofing can happen. > Mike> I have worked some with other vendor's IPsec when > Mike> troubleshooting interaction issues. I still believe that > Mike> IPsec at the base is not a good tunneling protocol. > > CISCO IOS IPsec is a poor tunneling protocol. > Many other vendors do a better job. Ohhh (blush) But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs are static, so there is only one peer where a particular source IP might come from. That is good for security, but poor for traffic engineering. We would like to have more than one path through the overlay network, and that requires some kind of routing protocol. And yes, such a routing protocol needs to be secure and not degenerate into a free-for-all. Whether any vendor provides that now is a subject for (intense) debate. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
