[cap-talk] network level designation and authorization

[Stephen J. Bevan]

David Hopwood writes:
 > coderman wrote:
 > > instead of httpsy[1], or captp[2] use a distinct VPN between service
 > > endpoints.  there may be only one service available at that endpoint.
 > > (just like a single service may be available at
 > > httpsy://*cl7h3f7jwyj3fvmw7jpnjfvf2xlcmayi@yurl.net/...)
 > 
 > This is so different from how a VPN is normally used that I would suggest
 > not describing it as a "VPN", even if the intention is to use crypto
 > protocols that are most commonly used to implement VPNs.

Perhaps I misunderstood the suggestion, but I read it as implying that
each separate service would, in IKE terms, have a separate phase1
configuration (containing one or more phase2 configurations allowing
access to specific addresses or ports) and thus you could only use the
services for which you had the necessary authority
(i.e. shared-secret, certificate or RSA key depending on what style of
phase1 authentication you choose to use).

That's different from a typical VPN only in that there an admin
statically determines the access a given client will require and thus
creates a single phase1 which contains one or more phase2s to allow
access to the desired services.  Clients in different categories
(e.g. engineers vs sales) are given access to different phase1
configurations.

However, there are (a minority of) VPNs where the client's access and
peering relationships need to change dynamically and those situations
are closer to what I understand coderman is proposing.  Typically it
is the peering relationships that needs to change most and so
solutions are geared towards that (e.g. Cisco's Dynamic Multipoint
VPN).  However, once you add the infrastructure to dynamically alter
the VPN policy on a node then you have the platform to support fine
grain policies of the sort that coderman is suggesting.