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

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

>
>>>>>> "Mike" == Mike Sullenberger <[email-masked]> writes:
>    Mike> We use other tunnel mechanisms (GRE), because IPsec tunneling mode
>    Mike> is lacking in functionality. For example, when you use GRE for the
>    Mike> tunneling you also reduce the IPsec SA's that are needed to
>    Mike> "describe" 
>    Mike> the traffic for IPsec to encrypt.  If you use IPsec tunnel mode only
>    Mike> then for each pairing of subnets behind each peer you need a separate
>    Mike> IPsec SA. For example if there are 5 subnets each behind two peers
>    Mike> then you need up to 25 SA pairs to describe exactly what needs to be
>    Mike> encrypted and nothing more.  If you tunnel the data traffic first
>    Mike> then
>    Mike> you only need 1 SA pair for all traffic, since IPsec encrypts the
>    Mike> tunnel itself and not the traffic within the tunnel. 
>
>So, you trade IPsec SAs ("security ACLs") for extended access-lists and
>routing tables.   I don't see a difference if both are automatically
>updated by a policy engine.
>
>I can see that this might matter for devices with fixed purpose ASICs
>that accelerate one kind of access list, but not another..

I am not sure where you are getting a set of extended access-lists. 
There aren't any extended access-lists added.  If a packet is routed
through the tunnel it is encapsulated and then encrypted. There isn't 
any access-list necessary. As for routing table, you have that in either
case.  With pure IPsec you don't run a routing protocol over the "tunnel"
but the peer (hub at least) still needs to advertise what subnets are
reachable through the VPN, especially in cases where you have alternate 
paths to get to the remote network. 

>    Mike> What you call other fancy features is what I call functional
>    Mike> separation. 
>    Mike> IPsec does encryption well, but in reality it does a fairly
>    Mike> poor job of  
>    Mike> tunneling. So lets have IPsec do what it does well and have
>    Mike> GRE do what 
>    Mike> it does well and that is tunneling.  Then you add NHRP do to
>    Mike> next-hop
>
>I'm curious if you've worked with any other vendor's IPsec?
>Because the issues you describe seem to be implementation limitations.

I have worked some with other vendor's IPsec when troubleshooting
interaction issues.  I still believe that IPsec at the base is not
a good tunneling protocol.  

>Still, I think that NHRP over GRE is a pretty good solution to the
>problem, particularily if in the end, you didn't want to actually have
>any ACLs on the resulting tunnels.

Mike.

>-- 
>]       He who is tired of Weird Al is tired of life!           |  firewalls  [
>]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
>] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>	               then sign the petition. 

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Nov 2011 13:17:11 -0500

>>>>> "Mike" == Mike Sullenberger <[email-masked]> writes:
    Mike> We use other tunnel mechanisms (GRE), because IPsec tunneling
    Mike> mode is lacking in functionality. For example, when you use
    Mike> GRE for the tunneling you also reduce the IPsec SA's that are
    Mike> needed to "describe" the traffic for IPsec to encrypt.  If you
    Mike> use IPsec tunnel mode only then for each pairing of subnets
    Mike> behind each peer you need a separate IPsec SA. For example if
    Mike> there are 5 subnets each behind two peers then you need up to
    Mike> 25 SA pairs to describe exactly what needs to be encrypted and
    Mike> nothing more.  If you tunnel the data traffic first then you
    Mike> only need 1 SA pair for all traffic, since IPsec encrypts the
    Mike> tunnel itself and not the traffic within the tunnel.
    >> So, you trade IPsec SAs ("security ACLs") for extended
    >> access-lists and routing tables.  I don't see a difference if
    >> both are automatically updated by a policy engine.
    >> 
    >> I can see that this might matter for devices with fixed purpose
    >> ASICs that accelerate one kind of access list, but not another..

    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!

    Mike> What you call other fancy features is what I call functional
    Mike> separation. IPsec does encryption well, but in reality it does
    Mike> a fairly poor job of tunneling. So lets have IPsec do what it
    Mike> does well and have GRE do what it does well and that is
    Mike> tunneling.  Then you add NHRP do to next-hop

    >> Because the issues you describe seem to be implementation

    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.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 01:36:14 +0200

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

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 20:31:44 -0500 (EST)

> 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 s…

So you want privacy, not security. IPsec is meant to deliver both.

>> Many other vendors do a better job.

Don't worry, we have interop issues with checkpoint too :) 
I'll buy dinner to the firs person showing me how to use the gui tools
to build rfc1918/XX <-> 0/0 on tcp 443 tunnel. Heck, I'll buy dinner
if you can do it with the cli command too.

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

Openswan supports MARKing the packet based on which SPI the packet
came out of, ip_conntrack then follows its around and reply packets
get the MARK as well, so we know which tunnel to send it to despite the
overlapping IP address on the client end. We even provide a setsockopt()
option so you MARK your socket before connecting to 192.168.1.1 and the
kernel knows which SPI to send the packet to. And each IPsec policy can
optin to allowing a range that would overlap.

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

If you need that, just run GRE with BGP on your routers connected with
simple static IPsec tunnels. Don't degrade the IPsec security within
the tunnels.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2011 04:17:17 +0200

> So you want privacy, not security. IPsec is meant to deliver both.

No, I want security, and this goes back to the administrative domain issue. If I have installed and configured all of the gateways in the overlay network, I could trust them enough to have the packets routed through any of them. With that assumption gone, I agree that your peer can spoof you.

> if you can do it with the cli command too.

I think this can be accomplished by adding some table entries in user.def, and the support database has instructions on this, but I'll admin that it's obscure enough that I can't find that out from here.

The UI is designed according to marketing requirements to answer what they believe customer needs are. I think that is true for all vendors.

> optin to allowing a range that would overlap.

Yeah, we do something similar. We are a stateful firewall, so every packet is associated with a "connection" (well defined for TCP, SCTP; kind of bogus for UDP), and every connection is associated with a tunnel, so outbound packets get to use the correct SA (or at least one matching the SA that inbound packets came through).

> simple static IPsec tunnels. Don't degrade the IPsec security within

I think that is a narrow, IPsec-centric view. It says that IPsec is secure and does not support dynamic SPDs in order to be secure. If you need dynamic tunnels, then use GRE, and then it's BGP (or RIP or OSPF) problem.

For network administrators (and thus vendors) it's their problem: they want both the security and the ability to get around failed links and nodes that routing provides for the Internet.

I would be happy to have an IKE/IPsec-only solution. But I don't think there is one now.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 12:06:15 -0600

> Yeah, we do something similar. We are a stateful firewall, so every packet is associated with a "connection" (well defined for TCP, SCTP; kind of bogus for UDP), and every connection is associated…

Oh, this is good news.  It means you're both close to having RFC5660
implemented :)

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2011 01:17:40 +0200

> Oh, this is good news.  It means you're both close to having RFC5660

Yeah, except without those pesky APIs. :-)

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 18:11:51 -0600

> Yeah, except without those pesky APIs. :-)

Sure, but adding those is relatively easy at that point.  You should do it :)