On Nov 15, 2011, at 7:08 PM, Yoav Nir wrote: Hi Yoav,
... >> We use other tunnel mechanisms (GRE), because IPsec tunneling mode >> is lacking in functionality. For example, when you use GRE for the >> tunneling you also reduce the IPsec SA's that are needed to "describe" >> the traffic for IPsec to encrypt. If you use IPsec tunnel mode only >> then for each pairing of subnets behind each peer you need a separate >> IPsec SA. For example if there are 5 subnets each behind two peers >> then you need up to 25 SA pairs to describe exactly what needs to be >> encrypted and nothing more. If you tunnel the data traffic first then >> you only need 1 SA pair for all traffic, since IPsec encrypts the >> tunnel itself and not the traffic within the tunnel. > >This was correct in IKEv1, but in IKEv2 you can have a bunch of ranges >for each traffic selector. Regardless, it has long been a (undocumented) >practice, by more than one vendor, to negotiate universal tunnels, so >that a single IPsec SA can be used for all the traffic between two peers. I will conceed that point. I have to admit that sometimes I still think in terms of IKEv1 instead of IKEv2. But, even with IKEv2 I think it is cleaner to only have to keep track of a simple policy, like encrypt anything that is GRE between these two peer IP addresses. >> What you call other fancy features is what I call functional separtion. >> IPsec does encryption well, but in reality it does a fairly poor job of >> tunneling. So lets have IPsec do what it does well and have GRE do what >> it does well and that is tunneling. Then you add NHRP do to next-hop >> resolution, which is what it was specifically designed to do, so that >> you can dynamically find peers and dynamically build new GRE tunnels >> protected by IPsec. Note, NHRP runs through the GRE tunnel so the >> single IPsec SA, since it encrypts the tunnel, also protects NHRP. >> Finally you add a routing protocol to advertise the reachablity of >> subnets/networks through the tunnel. Again this all goes through >> tunnel so the single IPsec SA protects this traffic as well. >> >> Basically you now have a system where you are using the proper tool >> to do the job that it was designed to do and that it does best. If you >> were to to try to overload these functions back into IPsec/IKE then >> you would end up with a less efficient system. > >I agree that this is a solution, but I don't agree that this is >necessarily the best solution. I'm also missing how trust is established, >and how advertising the reachability can be made secure. As long as you >don't have tunneling, a router can only lie to its neighbors, and even >that problem was severe enough that the SIDR group was set up to solve >it. Once you add tunneling, those lies can propagate all around the >world. So within the large overlay network, you either have to assume >that everyone "plays nice", or else you need some security mechanism to >secure these advertisements. The trust is established by the first that happens between peers is IKE using PKIX to establish authentication. Once IPsec SAs are setup then the we can send packets over the GRE tunnel. All packets within the tunnel are encrypted so you are assured that they are from the authenticated peer. Note, There are no packets that are part of the control plane or data plane of the tunnel that traverse outside the tunnel. It is true that if you trust that you have authenticated your peer, but don't trust what he may tell you then you have to take extra precautions. This is the same with pure IPsec. In that case IPsec knows what remote subnet are available through the VPN, and in order to propagate this information to the rest of the local network IPsec will need to inject this information into routing. I say that it is cleaner to use controls/ filters in the routing protocol to do this function, rather than trying to use controls/filters when you inject from IPsec into the routing protocol. Also when you inject from IPsec into the routing protocl (on the local side) you have lost quite a bit of information (For exmaple, dynamic metrics) versus actually running the routing protocol over the VPN. Note, the routing protocols have a long history of dealing with the trust issue between routing neighbors, and as you have pointed out they are continuing to deal with this (SIDR group). We should leverage their work rather than trying to duplicate it within IPsec. >To my mind, the security part of this is the real challenge, regardless >of whether we model IPsec tunnels as links or not. Yes, the security aspects are a very important piece and as usual "the devil is in the details". Mike. +------------------------------------------------+ | Mike Sullenberger; DSE | | m...@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
