Subject: Re: [IPsec] P2P VPN - Side Meeting

From: Mike Sullenberger <[email-masked]>
Date: Tue, 15 Nov 2011 18:24:17 -0800 (PST)

>Mike Sullenberger writes:
>> 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. 
>
>Not true. You can have one IPsec SA which have all subnets in both
>ends. There is no need to use multiple IPsec SAs in your example case.
>Multiple SAs is only needed if IPsec version which was obsoleted in
>year 2005 is used.

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
so the IPsec SA encryption SA is a single simple policy.  If the subnets
change then IPsec doesn't have to do anything.  Note, GRE doesn't have to
"worry" about this. Routing which is designed to deal with this does the
job.  The point is to make a layered solution, rather than trying to put
all functionality into a single layer.

>> What you call other fancy features is what I call functional separation.
>> 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.
>
>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. 

Mike.

>-- 
[email-masked]

+------------------------------------------------+
| Mike Sullenberger; DSE                         |
| [email-masked]                .:|:.:|:.         |
| Customer Advocacy              CISCO           |
+------------------------------------------------+

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2011 07:43:48 +0200

> 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... 

> run MPLS directly over IPsec. 

Ok, I assumed that we were still trying to be inside the IP-protocol
stack and forward IP-packets. 
-- 
[email-masked]