Mike Sullenberger writes: > I conceed the 1 IPsec SA issue, but with IPsec you still have to enumerate > all of the subnets within that SA and renegotiate when subnets are added > or removed. With GRE tunneling IPsec only ever sees the GRE tunnel packet
I most likely would need to read the draft to understand more correctly what subnets you are talking about. My understanding from the discussion on the list was that we wanted to connect multiple spokes connected to hubs to each other directly wihtout going through the hub. I understood that the subnets negotiated would be those between those two spoke systems, and they are usually quite stable, meaning there will be new subnets added only every few days/weeks/months, not every hour, thus the rekeying interval will be more frequent than the renegotation because of the changes in subnet lists. I might be wrong, as I have just tried to understand what people are doing by reading the discussion on the list... > >So you still didn't explain what GRE does better than modern IPsec > >tunneling? > > GRE is multiprotocol, an example is that I can run MPLS label switching > directly over GRE and then encrypt the GRE/IP packet, whereas I cannot > run MPLS directly over IPsec. Ok, I assumed that we were still trying to be inside the IP-protocol stack and forward IP-packets. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
