RE: VPN Auth (was VPN authentication/verification and WG re-chartering)

["Schliesser, Benson" <bensons at savvis.net>]

Hi, Ron.


Ron Bonica wrote:
> Schliesser, Benson wrote:
> > For instance, I would argue that there are several roles/modes of
> > authentication that must be considered: SP-managed, 
> user-managed, and
> > co-managed. Each of these modes have slightly different 
> requirements, of
> > course, and different alerting and/or response mechanisms.
> 
> Could you say a few words about what each of these terms means?

Sure.

The essence of what I'm referring to by each of these "modes" is the
answer to the question, "who cares?". For whatever reason ("managed"
product offering, associated SLA, etc) the SP may care about whether
invalid sites are attached to the VPN. In the simplest case this may
just provide a point of measurement for the SP to know if there has been
a provisioning mistake. In other cases this may trigger a response
process by the SP, SLA credits/payments, etc. This is what I mean by
"SP-managed". Similarly, the customer/user may also care. Clearly the
customer may have security concerns. There may also be vendor-management
issues, such as SLA-credit requests. This is what I mean by
"user-managed". The hybrid "co-managed" case is where the SP and the
user both care.

I imagine that for each of these modes, the notable difference is who
has access to which authentication keys. I don't want to presume to know
what form the keys take, whether there are one or more, etc. But I do
assume that the verification process will require some knowledge of key
data, which may need to exist independently for the SP and user, or in a
mode which can be shared, etc.

When I refer to "alerting" mechanisms, I mean for instance that the PE
or CE may issue alarms (SNMP traps, CLI messages, etc). By the term
"response" I mean something automated, such as I.e. a PE-based mechanism
to automatically shutdown interfaces that fail authentication.

As Tom pointed out in his message, the multi-provider case just
exacerbates this issue. For instance, does the user have a direct
relationship with each provider or is there a single provider that is
responsible for the customer relationship and acts as a management proxy
for the other providers? This may impact who has access to which keys...
Etc.  Another scenario, which occurred to me after my previous post, is
the extranet case where there are multiple (untrusting) users connecting
to the same L3VPN.


> > Across all of these modes the primary goal is to be assured that all
> > sites attached to the VPN are intended and allowed to be members.
> > Secondary goals *might* include verification that the CE 
> was configured
> > by the correct authority (i.e. is not a hacked or replaced 
> device), that
> > routes originating from the CE (or PE) are legitimate, etc. Maybe a
> > solution for one of the secondary goals might actually 
> solve the primary
> > goal, too.
> 
> Could you say a few words about the secondary goals?

There may be other secondary goals, in addition to the ones I mentioned
here. But I'll be glad to explain the ones I brought up.

The "verification" goal is possibly a tough one...  What I mean is that
the authentication mechanism can indicate whether the CE was modified or
replaced. For instance if a SP is offering a fully-managed service,
where they are responsible for the CE device and configuration, can they
know if the user unplugs the SP-managed CE and replaces it with their
own? (Or an untrusted third party does it?) If the authentication
mechanism is based only on key information which may in fact be shared
between the SP and user then this might be hard to detect. Conversely if
there was some information (CE secret identity, configuration serial
number, etc) that worked in conjunction with the authentication key,
then perhaps this activity could be detected.

The "route legitimacy" goal is more straight-forward, I think. The
authentication mechanism might provide the ability for a network element
to verify that routes are in fact allowed to originate from their source
PE or CE. There are variations on how this could be done. Some of the
SIDR work, for example, might apply.


Do these comments make sense? If it would be useful, I'll be glad to say
even more words. ;) But I'd like to get some feedback and invite others
to challenge or contribute to the discussion.

Cheers,
-Benson