Subject: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2012 08:00:16 +0200

In section 2.1 where there is dicsussion about the endpoint to
endpoint vpn use case, it should be noted, that this might require
different temporary credentials. Endpoints (especially remote access
users) do use passwords or similar credentials which cannot be
forwarded. I.e. if the shared secret is used to authenticate the end
node to the gateway, that same shared secret cannot be given to the
another end point as that would allow it to impersonate the first
peer. Also the endpoint most likely cannot access the same AAA server
than what security gateway does, so if peer uses EAP to authenticate
itself to the security gateway, the endpoint to endpoint vpn cannot
use the same credentials.

This means that we might need to add creation of temporary credentials
to the protocol.

In section 3.1 exhaustive configuration I think it is incorrect to
claim it does not scale, as if the configuration is pushed to all
devices using some kind of out of band configuration tool it is
completely possible to make extreamly large setups. Dynamic updates
do cause some problems there, as every change might require policy to
be pushed to every single node. I think the main problem with this
setup is that it requires that out of band configuration system, and
those are proprietary which means you cannot use implementations from
different vendors. 

In section 3.2 about star topology it should be noted, that quite
often adminstrators do require star topology because they want to do
some kind of inspection for all traffic inside the vpn. This kind of
policy might make it impossible to do endpoint to endpoint
connections, and might limit which kind of gateway to gateway cases
are allowed.

I do not see how the last paragraph in section 3.2 does not seem to
belong there:

   The challenge is how to build large scale, fully meshed IPsec
   protected networks that can dynamically change with minimum
   administrative overhead.

The section 3.2 talks about existing star topology solutions, and
making large scale fully meshed network is not even in scope for such
systems.

In section 3.2 we should also mention that with proprietary approaches
it is not clear whether they implement all checks required by the
IPsec architecture, i.e tunnel exit checks, firewall rules, security
policy checks etc. They might do those, or they might skip them...

In general the current use case description was quite good, and I
think this document is good start. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Mar 2012 09:45:39 +0200

> use the same credentials.

Users use passwords, but endpoints can use PSKs and certificates. PSKs should be pairwise, so they have to be provisioned dynamically. It's all part of having to create the PAD entries dynamically. If we anyway have to provision peer's IP address/locator and identity (DN, username) we might as well also provision a PSK.

If we really want to authenticate users, we need to use EAP to authenticate to some trusted (by whom?) server. Then we can extend that authentication to other endpoints and gateways that are not connected to the same AAA server, perhaps using some mechanism like tickets or session resumption or ERP, or by having the gateway provision the shared secrets for the client and the other peers.

> This means that we might need to add creation of temporary credentials

I think that unless we are going to mandate a system based solely on certificates, that's a given.

> those are proprietary which means you cannot use implementations from

Take a company the size of IBM. They have 400,000 employees. Probably hundreds of thousands of smartphones, hundreds of thousands of PCs, and thousands of VPN gateways. It doesn't make sense that each smartphone holds the entire PAD for all this, and we haven't even mentioned partners and customers yet.  You could keep a kind of star topology, where the phones are secondary nodes, and they connect to some primary nodes (using IKE or something else). When they need to connect to some other primary or secondary node, they get that information from the primary node.

And you can have the primary nodes know everything, or make it hierarchical or DNS-based or something else entirely. This discovery mechanism is a big part of the charter item, and I think it should avoid having to push the entire policy to each endpoint.

> connections, and might limit which kind of gateway to gateway cases

That's a matter of policy. Sometimes they want to inspect traffic going in and out of their organizational VPN, but not traffic flowing within it. So traffic from the Maastricht office can flow freely to the Quebec City office, and doesn't have to go through the New York datacenter. But traffic going to Facebook needs to be scanned, and goes through the datacenter.

> making large scale fully meshed network is not even in scope for such

I think the point of section 3.2 is that stars are defined partly because they're easier (just one credential to configure on each satellite). The challenge is to overcome the difficulty in defining a mesh.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2012 20:13:22 +0200

Yoav Nir writes:
> Users use passwords, but endpoints can use PSKs and certificates.
> PSKs should be pairwise, so they have to be provisioned dynamically.
> It's all part of having to create the PAD entries dynamically. If we
> anyway have to provision peer's IP address/locator and identity (DN,
> username) we might as well also provision a PSK. 

I think this is something that should be pointed out in the use case
for endpoint to endpoint scenario. Just to make it clear. Also adding
note about that to the security considerations section is also needed. 

> If we really want to authenticate users, we need to use EAP to
> authenticate to some trusted (by whom?) server. Then we can extend
> that authentication to other endpoints and gateways that are not
> connected to the same AAA server, perhaps using some mechanism like
> tickets or session resumption or ERP, or by having the gateway
> provision the shared secrets for the client and the other peers. 

I would actually think short lived certificates would be better and
much more scalable way to provide temporary credentials. 

> Take a company the size of IBM. They have 400,000 employees.
> Probably hundreds of thousands of smartphones, hundreds of thousands
> of PCs, and thousands of VPN gateways. It doesn't make sense that
> each smartphone holds the entire PAD for all this, and we haven't
> even mentioned partners and customers yet.  You could keep a kind of
> star topology, where the phones are secondary nodes, and they
> connect to some primary nodes (using IKE or something else). When
> they need to connect to some other primary or secondary node, they
> get that information from the primary node. 
> 
> And you can have the primary nodes know everything, or make it
> hierarchical or DNS-based or something else entirely. This discovery
> mechanism is a big part of the charter item, and I think it should
> avoid having to push the entire policy to each endpoint.

In most of those big enterprices they already have some kind of tools
to push policy and configuration to every single device. They might
not even allow device to connect to the network before they can verify
that the device has up to date configuration and policy. As far as I
understand this is already standard working practices they are doing
now, and claiming you cannot do that is bit misleading.

But as I sid they do require some out of band policy distribution
mechanisms which are not standardized... 

> That's a matter of policy. Sometimes they want to inspect traffic
> going in and out of their organizational VPN, but not traffic
> flowing within it. So traffic from the Maastricht office can flow
> freely to the Quebec City office, and doesn't have to go through the
> New York datacenter. But traffic going to Facebook needs to be
> scanned, and goes through the datacenter. 

Yes, and I think the star topology section should point out that in
some cases the topology is required because of the policy reason, as
this do affect our scope / use cases.

> I think the point of section 3.2 is that stars are defined partly
> because they're easier (just one credential to configure on each
> satellite). The challenge is to overcome the difficulty in defining
> a mesh. 

I think that paragraph should then be modified to say that... 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2012 14:08:08 -0400

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    Tero> This means that we might need to add creation of temporary
    Tero> credentials to the protocol.

This is an interesting question.
I think the requirements document needs to either make this in scope or
make it out of scope by requiring re-usable mechanisms of
authentication.

    Tero> In section 3.2 about star topology it should be noted, that
    Tero> quite often adminstrators do require star topology because
    Tero> they want to do some kind of inspection for all traffic inside
    Tero> the vpn. This kind of policy might make it impossible to do
    Tero> endpoint to endpoint connections, and might limit which kind
    Tero> of gateway to gateway cases are allowed.

So, then don't deploy DMVPN or whatever it's gonna be called.
Is this for the applicability statement then?

-- 
]       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: Tero Kivinen <[email-masked]>
Date: Thu, 15 Mar 2012 20:49:10 +0200

> Is this for the applicability statement then?

As this "star topology" section is in "Inadequacy of Existing
Solutions" section, so adding note that some people still want to use
the existing solution because of these reasons, might be good thing so
we do not need to try to solve that in our solution.
-- 
[email-masked]