OK. Routing protocols are not security protocols. That's fine. Neither is HTTP.
BGPSEC and SIDR implement a layer of security on top of BGP to overcome this issue, and that may be used in the Internet. OSPF and NHRP are designed to be used in closed environments (corporate networks), where everyone is assumed to be "playing nice", so there has never been as much requirement for a security layer, and in fact there is no security layer to NHRP. When you extend NHRP to an overlay network over the Internet, as you do with GRE, you are still fine as long as everybody "plays nice". With the obvious example of a corporate network with tunnels to the branches in New York, London, Paris, and Shang-hai you're still fine, because all the gateways are configured by the same person or organization, or at least they are part of the same hierarchy, although by this point you may need to be worried about misconfiguration. With a multiple-administrative-domain use case, all bets are off. What would prevent a gateway anywhere from claiming responsibility for the addresses of the facebook.com server? That would cause several bad things: - that gateway gets access to all facebook traffic in the entire overlay network - all the gateways have to work extra hard encrypting facebook content for no reason at all. This is a real problem regardless of whether we use IPsec tunnels or GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever solution we pick (as a working group) we will still need to develop a security layer, which may or may not be based on what the BGP people are doing. This is especially important for cross-domain use cases, but would be very helpful for same-domain as well. Yoav On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote: > > Security is a matter of architecture and end-to-end design. Several > mechanisms are used to achieve an efficient balance with complexity. Features > and security protocols are only building blocks. > > IPsec and IKE are not the only features that protect a network and routing as > a security policy really is not a problem until shown otherwise. > > Again, I urge you to be specific because there is nothing tangible in your > claims. I understand what you mean but if you rationalized it, you would see > your intuition fools you. > > > On 16 Nov 2011, at 14:17, Yoav Nir wrote: > >> >> On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: >> >>> Yoav Nir writes: >>>>> So you still didn't explain what GRE does better than modern IPsec >>>>> tunneling? >>>> >>>> I think GRE (or any tunnel that is not IPsec - like L2TP) allows >>>> them to avoid having to deal with RFC 4301 stuff like SPD. The only >>>> selector they need is for the GRE tunnel (protocol 43?) or the L2TP >>>> tunnel (UDP 1701). >>> >>> I.e. bypass the security mechanishms provided the security protocol. >> >> Yes! >> >>>> That means that your security policy is effectively determined by >>>> the routing protocol. >>> >>> I.e. move the security from the security protocol to something else >>> which is not a security protocol. Is this really something we want to >>> do? >> >> Define "we" >> >>> Who is going to make sure the end result is secure? >> >> The customer >> >> > > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
