Subject: Question:draft-ietf-l3vpn-l3vpn-auth-01

From: Raveendra Torvi <[email-masked]>
Date: Fri, 25 Feb 2005 14:38:50 -0500

Hi,
I had generic question on CE-CE Authentication.
Let's say a customer changes his authentication key (token)  bi-weekly 
for security purpose. Then how would one manages token synchronization 
among the CEs and avoid service interruption.
Thanks,
-Ravi-

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 25 Feb 2005 15:22:08 -0500

Ravi,

The CE router has a few choices in this regard. The draft says that if a 
CE router receives a token that it does not recognize, it can take 
whatever action that its security policy dictates. The following are two 
possible policies:

1) CE isolates itself from the VPN and emits an alarm
2) CE remains connected to the VPN and emits an alarm

If the CE implements the first policy, sometime before the transition, 
you will want to configure each CE router so that it will accept two 
tokens. These represent a) this week's token and b) next week's token. 
So, service will not be interrupted during the transition.

If the CE implements the second policy, you don't need to be so careful. 
You can let the CE emit an alarm and configure your NMS to ignore the 
alarm if it contains last week's token

                                          Ron

---

From: Raveendra Torvi <[email-masked]>
Date: Fri, 25 Feb 2005 16:39:02 -0500

Thanks Ron,
Can you please clarify one more doubt on the following section/paragraph,

2.  Overview

.....
.....

   If a customer device receives a token that it does not recognize, it
   issues an alarm requesting operator intervention.  The customer
   device may also withdraw from the VPN, neither sending traffic to the
   VPN nor accepting traffic from it until an operator clears the
   security condition.

My Assumption : A misconfigured PE can send a VPN token to unrelated VPN 
customer(s).

What if a malicious customer's CE does not complain about it and keeps 
sniffing some other VPN customer's traffic. How would a VPN customer 
trust the other VPN customer 's policy.( unless all the CE's are managed 
by the provider.)
Am I missing something here ?
Thanks,
-Ravi-

Ronald Bonica wrote:

> Ravi,
>
> The CE router has a few choices in this regard. The draft says that if 
> a CE router receives a token that it does not recognize, it can take 
> whatever action that its security policy dictates. The following are 
> two possible policies:
>
> If the CE implements the second policy, you don't need to be so 
> careful. You can let the CE emit an alarm and configure your NMS to 
> ignore the alarm if it contains last week's token
>
>                                          Ron
>
>
> Raveendra Torvi wrote:
>
>> Hi,
>> Let's say a customer changes his authentication key (token)  
>> bi-weekly for security purpose. Then how would one manages token 
>> synchronization among the CEs and avoid service interruption.
>> Thanks,
>> -Ravi-
>>
>

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 25 Feb 2005 21:50:36 -0500

Ravi,

In order to join a VPN, a VPN site must give the PE to which it is 
attached a token*. The PE distributes this token to all directly 
connected CEs that participate in the VPN. The PE also distributes the 
token to all remote PEs. The remote PEs, in turn, distribute the token 
to all CEs contained by the VPN.

Tokens follow connectivity. If a VPN site is joined to a VPN, the token 
that represents that site will be distributed to all sites contained by 
the VPN.

The Service Provider may provision Customer A's site into Customer B's 
VPN. When that happens, Customer A's token will appear at *all* of 
customer B's sites and *all* of Customer B's CE routers will complain. 
Likewise, Customer B's tokens will appear at Customer A's misconfigured 
site.

It doesn't matter if Customer A keeps quiet about the situation. 
Customer B will know that something is wrong.

In this example, we assume that Customer A and Customer B manage their 
own CE routers.

                                 Ron

* There is one exception to this rule in which the PE assigns a NULL 
token. See the draft for details.