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

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

Hi Yoav,

    Please see inline.

Mike.

>On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
>
>>
>> On 15 Nov 2011, at 12:05, Yoav Nir wrote:
>>
>>> Hi Frederic
>>>
>>> Inline...
>>>
>>> On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
>>>
>>>> Hi Yoav,
>>>>
>>>> We will be there (following offline with you for the details).
>>>>
>>>> I do not think there is a need to spend 20 minutes on the draft
>>>> which everyone should have read. There are three vague points in
>>>> it and 10 min seem largely sufficient.
>>>
>>> 20 minutes includes time spent on hellos, introductions, asking
>>> if everyone has read the draft, jabber scribe, testing the audio,
>>> and all other kinds of administrivia. You've been to IETF sessions
>>> before, and you know how that goes.
>>
>> absolutely. Then we agree on the 20 min.
>>
>>>> At this stage several vendors think they have a fair
>>>> understanding of the requirements and a gap analysis is much more
>>>> productive and constructive. I have just asked Chris Ulliott to
>>>> provide his feedback in case audio fails on us. We can factor his
>>>> reply in the discussions.
>>>
>>> To me the biggest gap in existing solutions is that they require
>>> kludges like GRE tunnels and route-based VPN, and also that they
>>> don't cover the provisioning of credentials. GRE tunnels and
>>> route-based VPNs I consider a kludge because you are then required
>>> to treat VPN tunnels as interfaces. Interfaces are much more
>>> resource intensive when compared to simple SAs, and most operating
>>> systems are very limited in the number of interfaces that they
>>> support.
>>
>> These are all very vague but generally misinformed statements.
>
>I'm sorry if they have offended you or your company.
>
>My point remains, that IPsec does define a mechanism for tunneling
>packets. It's called "tunnel mode IPsec". That Cisco and perhaps
>other vendors choose to use other tunneling mechanisms such as GRE
>when they need some fancy features such as peer discovery or dynamic
>protected domain discovery, tells me that something is lacking in
>IPsec tunnels. That is what I meant by "kludge".
>
>It may be that the problem with IPsec tunnels is not in the tunnels
>themselves, but that there are no configuration protocols associated
>with them, such as the routing protocols or such as NHRP that can be
>used with GRE tunnels.
>
>I will take your word that using GRE+NHRP can scale as far as anyone
>would like. However, in evaluating solutions, we should not
>automatically go with the analogy that IPsec VPNs are like overlay
>networks on top of the Internet, and that tunnels are analogous to
>links. GRE is an overhead that is added to every packet. NHRP is yet
>another protocol that needs to be implemented and carried over the
>IPsec SA. All that should be compared with cost and complexity of
>potential extensions to IKE and IPsec that would carry the same
>information.
>

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. 

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

>We will have plenty of opportunity to discuss these things at the
>meeting on Wednesday, but just to make things clear, I am not
>advocating any solution, and I have no unsubmitted draft with some
>extension to IKE. The purpose of the meeting is to review the use
>cases and the solutions that currently exist. If anyone intends to
>pull out a new never-before-published solution that's fine as well,
>but I have no such intentions.
>
>Yoav
>
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 13:08:31 +0200

Hi Mike

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

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

To my mind, the security part of this is the real challenge, regardless of whether we model IPsec tunnels as links or not.

Yoav

---

From: "Ulliott, Chris" <[email-masked]>
Date: Tue, 15 Nov 2011 11:36:10 +0000

Classification:UNCLASSIFIED

The problem with a single SA is that it usually means a single key (what ever form that takes) such that a compromise of a single spoke puts all traffic at risk... So what ever solution we go for - we need to keep one eye on the security requirements...

Chris

[This message has been sent by a mobile device]

----- Original Message -----
From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, November 15, 2011 11:08 AM
To: Mike Sullenberger <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [IPsec] P2P VPN - Side Meeting

Hi Mike

Yoav

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Nov 2011 14:53:50 +0200

> The problem with a single SA is that it usually means a single key (what ever form that takes) such that a compromise of a single spoke puts all traffic at risk... So what ever solution we go for -…

Hi Chris

I don't mean a single SA for the whole configuration. I mean a single SA for every pair of gateways, rather than lots of SAs, one for each pair of subnets.

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 15 Nov 2011 22:10:21 +0800

What you are referring to is when a single SA/key is shared across multiple devices (or the entire network). Here, we are talking about a unique SA pair between any two devices. I.e. each device pair on the network has its own IPsec SA.

	fred

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 10:03:23 -0500

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

    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.

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.

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

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 07:40:03 +0800

On 15 Nov 2011, at 23:03, Michael Richardson wrote:
[...]
> that accelerate one kind of access list, but not another..  

The net effect is the number of negotiations is greatly reduced when there are many prefixes in play.

[...]
> Because the issues you describe seem to be implementation limitations.

we actually do have both types of implementations. In practice, we find IPsec + tunneling largely superior. Less negotiations, easier to troubleshoot and scale.

The peer discovery issue is really is an overlay / transport (network virtualization) problem that is well solved outside of IPsec and tunnels just made sense.

thanks,

	fred

---

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

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

> it does well and that is tunneling.

So you still didn't explain what GRE does better than modern IPsec
tunneling?
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 04:51:23 +0200

> So you still didn't explain what GRE does better than modern IPsec

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

That means that your security policy is effectively determined by the routing protocol.

Yoav

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 11:41:19 +0800

And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With "modern ipsec tunneling" (got to love that), there is still a lot of negotiation going on.

We are talking about potentially hundreds of subnets behind a branch here.

---

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

Yoav Nir writes:
> 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. 

> That means that your security policy is effectively determined by

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? Who is going to make sure the end result is secure?
-- 
[email-masked]

---

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

Frederic Detienne writes:
> And like I said earlier, the amount of negotiation when there are
> multiple prefixes to protect is limited to one. With "modern ipsec
> tunneling" (got to love that), there is still a lot of negotiation
> going on. 

I do not understand what you are trying to say there. 

> We are talking about potentially hundreds of subnets behind a branch

Really? There must be something really, really wrong in their
IP-address allocation in that case. Usually the one branch has only
few subnets as it would make adminstration really hard if you put
hundreds of separate subnets in the same branch office.
-- 
[email-masked]

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 14:05:53 +0800

> I do not understand what you are trying to say there. 

even with "modern ipsec tunneling", one selector has to be negotiated for each pair of prefixes to protect. This can amount to a lot of selectors to negotiate in practice.

> hundreds of separate subnets in the same branch office.

Really and there is nothing wrong.

It is your view that these are "branch offices". A spoke is only a branch from a topology standpoint but the actual spoke device may protect a very large networks at very high throughput.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 08:17:01 +0200

> I.e. bypass the security mechanishms provided the security protocol. 

Yes!

> do?

Define "we"

> Who is going to make sure the end result is secure?

The customer

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 15:11:08 +0800

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.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2011 09:31:15 +0200

Frederic Detienne writes:
> 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. 

When one does not know what problem we are really solving and what
security and other requirements that problem has, it is very hard to
be specific about anything.

On the other hand when some comments related to the problems that were
fixed more than 5 years ago (and that work was started EXACTLY 10
years ago), so that does affect my feeling on the issue.

Btw. draft-ietf-ikev2-00 was published 2001-11-16....
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 09:35:28 +0200

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:

> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2011 09:38:27 +0200

Frederic Detienne writes:
> even with "modern ipsec tunneling", one selector has to be
> negotiated for each pair of prefixes to protect. This can amount to
> a lot of selectors to negotiate in practice.

Not for each pairs of prefixes, but for one selector for each subnet
in total. I.e. if one end has 10 subnets and another has 100, then you
need 10 initiator traffic selectors and 100 responder traffic
selectors. 

> It is your view that these are "branch offices". A spoke is only a
> branch from a topology standpoint but the actual spoke device may
> protect a very large networks at very high throughput. 

Then I have completely misunderstood what this work is about. I had
understood we are doing mesh setup, where everybody may connect to
anybody, i.e. traffic goes directly from one node to another node, not
through other nodes, i.e. no branches and routers on the way, but only
direct connection between two peers.

BTW, if there is really going to be hundreds of subnets, then we do
need to use multiple SAs as Number of TSs is only 8-bit field, so
there can be only 255 traffic selects per peer... 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 09:41:57 +0200

> Btw. draft-ietf-ikev2-00 was published 2001-11-16....

draft-ietf-ipsec-ikev2-00

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 09:58:14 +0200

> need 10 initiator traffic selectors and 100 responder traffic

You could even negotiate universal selectors (0.0.0.0-255.255.255.255) and then use some other source of policy (for example: the subnet attribute in the configuration payload). I think that is what Microsoft's IKEv2 clients do, but it has been over a year since I looked at it, so I may be wrong.

We could document an "any" selector.

---

From: Frederic Detienne <[email-masked]>
Date: Wed, 16 Nov 2011 17:23:43 +0800

You are mixing everything up. It is too much work to correct you over email. I will try to help you at the meeting.

regards,

	fred

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 16 Nov 2011 06:13:32 -0500

I think we will benefit greatly if we focus tonight's
meeting mainly on discussion of and perhaps agreement
on the PROBLEM TO BE SOLVED.

Comparison and analysis of proposed solutions should
wait until we have agreed on the problem statement
and the requirements derived from that. And, as we've
just seen, it's very hard to have a clear discussion
of different alternative proposals without having
those proposals described in detail as Internet-Drafts.

The goal of the 7 minute presentations of solutions
tonight (as I understand it) is simply to show that
there are some interesting solutions out there, not
to promote comparisons of them. I already regret
the decision to include those solutions on the agenda
since we've now spent lots of time insulting each
others' approaches without actually understanding them.

Please let's skip more shouting matches about solutions
tonight. We don't have enough facts on the table.
Instead, let's focus on discussing which problem
we should be trying to solve.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Frederic Detienne
> Sent: Wednesday, November 16, 2011 4:24 AM
> To: Yoav Nir
> Cc: [email-masked] WG; Tero Kivinen; Mike Sullenberger
> You are mixing everything up. It is too much work to correct you over
> email. I will try to help you at the meeting.
> 
> regards,
> 
> 	fred
> 
> > 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:
> > 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.
> >
> >> 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.
> >>
> in your claims. I understand what you mean but if you rationalized it,
> you would see your intuition fools you.
> >>
> >>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2011 13:35:50 +0200

OK. A dumber but more practical question: Do you have any idea how we can get microphones? 

The projector is indeed here, but the microphones seem to be missing.

Keeping the audio stream running all night doesn't help if the mikes are gone...

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2011 12:37:19 -0500 (EST)

> We are talking about potentially hundreds of subnets behind a branch here.

And it is great that those subnets will not be able to be spoofed from other
branches!

Reverting to a 0/0 <-> 0/0 policy is less secure and imho, lazy :)

Paul