Subject: VPN authentication/verification and WG re-chartering

From: Rick Wilder <[email-masked]>
Date: Tue, 5 Jun 2007 02:06:23 -0700 (PDT)

L3VPN participants,

As was mentioned at the Prague meeting and on this email list, Ron, Mark, and I are
currently updating the charter for the L3VPN WG. 
 
When Ron called for work items that need to be undertaken by the WG, Shane Amante
recommended reviving the VPN authentication/verification
work that was started some time back, but not completed. (his email copied below)
 
In order for this to be included in the WG charter, we need to hear some more support for
this work item within the next 10 days. 
If VPN authentication/verification is of importance to you, please weigh in before
re-chartering is completed.
 
Rick

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Ron Bonica wrote:
> Folks,
> 
> We are considering an update to the L3VPN WG charter. In the new
> charter, VPN Multicast will remain high on our list of work items. So
> far, the only request for a new work item has been "MPLS services
> delivered over L3VPN infrastructure". (See
> draft-kumaki-l3vpn-e2e-rsvp-te-reqs).
> 
> Would anyone else like to recommend work items for inclusion in the charter?

I agree VPN multicast should be a high priority for the WG.

In addition, I would also recommend that the WG look at solving for two 
additional things:
1)  iBGP PE-CE
http://www.watersprings.org/pub/id/draft-marques-l3vpn-ibgp-01.txt
At a minimum, we should look at publishing this as an Informational 
Draft -- since, to my knowledge, there is at least 1 major 
implementation that does this today.  Note, I don't think we need to put 
this in the charter if it's just going as Informational, unless it has a 
significant affect on many other drafts & RFC's ... so, perhaps this is 
just a small "todo" item.

2)  "Layer-3 Import/Export Verification".  According to the archives, 
there appears to be at least 3 different WG drafts:
http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00
http://tools.ietf.org/html/draft-ietf-l3vpn-l3vpn-auth-01
http://tools.ietf.org/html/draft-ietf-l3vpn-vpn-verification-00
... although, it appears as if the first two are the same draft, just 
with a title change.  Regardless, all three drafts have expired over the 
course of the last 2-4 years.

I realize there is also work occurring in tcpm, sidr, and, perhaps, 
others to secure various elements of BGP (key rollover, securing path 
update messages, etc.).  However, its not clear what is the time horizon 
to complete that work, and more importantly whether they have adequate 
reqmt's to: a) deliver 'lightweight' solutions for IPVPN's; and, b) will 
be able to adequately accomodate some properties unique to IPVPN's that 
aren't applicable to the general Internet, (e.g.: AS_OVERRIDE).

In summary, I would propose we do two things for this one:
1)  Complete the work on at least one of the outstanding l3vpn vpn 
verification drafts; and,
2)  Look at specifying reqmt's for sidr, or other relevant WG's, to 
accomodate reqmt's unique to L3VPN's to secure the control plane.

-shane

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 5 Jun 2007 08:13:19 -0500

I agree that a) VPN authentication should be included in the new
charter. In my experience as a SP, concern over "security" is one of the
most common reasons that users choose against L3VPN services. ("Control"
being the other common reason.) To whatever extent authentication
mechanisms can provide validation of the VPN membership and routes, I
think it will be a valuable component of a L3VPN service. I would like
to see discussion of the requirements first, so that candidate solutions
have a point of reference.

I also agree with Shane's message that b) multicast in L3VPN and c) iBGP
as PE-CE protocol should also be driven to completion, possibly in the
charter.

And finally, I also think that more discussion is needed around d)
inter-provider L3VPN interconnection. I understand that discussion
around this topic is happening in other forums, and I believe it would
be useful if some of that discussion "came home" to influence this WG.
Specifically, most providers with whom I speak are confounded by their
desire to run "option B" for scale and management reasons versus their
need to run "option A" due to implementation issues and complexity,
feature constraints, etc. Perhaps the charter should reflect this topic,
or perhaps this should be relocated to another WG?

Cheers,
-Benson

> -----Original Message-----
> From: Rick Wilder [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 10:06 AM
> To: [email-masked]
> Cc: Shane Amante
> Subject: VPN authentication/verification and WG re-chartering
> 
>  
> L3VPN participants,
>  
>  
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> -------------------
> 
> 
> Ron Bonica wrote:
> > Folks,
> >

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 5 Jun 2007 08:21:39 -0500

Sorry for replying to my own message, but I would like to encourage
discussion around VPN Auth requirements.

> I would like to see discussion of the requirements first, so that 
> candidate solutions have a point of reference.

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.

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.

Any thoughts on these goals, and/or how they translate into technical
requirements?

Cheers,
-Benson

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 5 Jun 2007 10:26:45 -0400

> course, and different alerting and/or response mechanisms.

	And one other thing related to an important point you raised
earlier related would be two other cases: multiple SP-managed, co- 
managed
with multiple SPs where there are multiple providers.

	--Tom

---

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 5 Jun 2007 11:03:08 -0500

Tom-

That's a good point. It can (easily) be argued that these multi-SP cases
are actually the most important for VPN authentication to address...
Certainly, the trust models are complicated. I.e. who owns the customer
relationship, who is managing the service(s), etc. But in any case,
there are too many contributors in the VPN for things to just work
without occasional error. VPN authentication is very valuable in this
environment.

Cheers,
-Benson

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 3:27 PM
> To: Schliesser, Benson
> Cc: [email-masked]
> Subject: Re: VPN Auth (was VPN authentication/verification 
> and WG re-chartering)
> 
> 
> > by the correct authority (i.e. is not a hacked or replaced 
> device),  
> > that

---

From: Ron Bonica <[email-masked]>
Date: Tue, 05 Jun 2007 17:11:10 -0400

> course, and different alerting and/or response mechanisms.

Could you say a few words about what each of these terms means?

> solution for one of the secondary goals might actually solve the primary

Could you say a few words about the secondary goals?

                                 Ron

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 7 Jun 2007 18:08:13 -0500

Hi, Ron.

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

> device), that

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

---

From: <[email-masked]>
Date: Mon, 11 Jun 2007 17:54:36 +0100

Rick,

Rick Wilder <mailto:[email-masked]> wrote:
> As was mentioned at the Prague meeting and on this email
> list, Ron, Mark, and I are currently updating the charter for
> the L3VPN WG.
> 
> When Ron called for work items that need to be undertaken by
> the WG, Shane Amante recommended reviving the VPN
> authentication/verification work that was started some time
> back, but not completed. (his email copied below)
> 
> If VPN authentication/verification is of importance to you,
> please weigh in before re-chartering is completed.

I support VPN authentication/verification being added to the charter as
it is a useful tool to ensure that the actual state stored by the
routers matches what the OSS systems have configured the network to look
like thereby enabling the detection of misconfigured routers.

I also support the continued inclusion of VPN multicast as a high
priority work item and agree with Shane that it would be useful to
publish the iBGP PE-CE draft in some form.

Ben

-- 
Ben Niven-Jenkins
Network Architect, BT
  
E-mail: [email-masked] 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827