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

Tero Kivinen <kivinen@iki.fi> Wed, 14 March 2012 06:00 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20320.13296.969392.797484@fireball.kivinen.iki.fi>
Date: Wed, 14 Mar 2012 08:00:16 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
Subject: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00
Precedence: list

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. 
-- 
kivinen@iki.fi

[IPsec] Some comments to the draft-ietf-ipsecme-p… Tero Kivinen
Re: [IPsec] Some comments to the draft-ietf-ipsec… Yoav Nir
Re: [IPsec] Some comments to the draft-ietf-ipsec… Tero Kivinen
Re: [IPsec] Some comments to the draft-ietf-ipsec… Michael Richardson
Re: [IPsec] Some comments to the draft-ietf-ipsec… Tero Kivinen