Subject: draft-ietf-l3vpn-l3vpn-auth-00 and draft-behringer-mpls-vpn-auth-02.txt

From: Ross Callon <[email-masked]>
Date: Thu, 18 Sep 2003 16:54:54 -0400

The L3vpn chairs would like to solicit comments on the two drafts: 
         draft-ietf-l3vpn-l3vpn-auth-00; and 
         draft-behringer-mpls-vpn-auth-02.txt 

The first of these was first discussed March 2002 at the 53rd 
IETF Meeting in Minneapolis, (see 
http://www.ietf.org/proceedings/02mar/index.html) and was 
accepted as a working group document sometime after this. 
  
The second was discussed at the 56th IETF in San Francisco this 
past March (see http://www.ietf.org/proceedings/03mar/index.html). 
  
Both of these drafts address the problem of a SP provisioning 
a VPN site into the wrong VPN. The two drafts differ in approach. 
  
The most obvious question is whether we want to progress both 
drafts separately. In other words, do the approaches differ 
sufficiently in terms of how they work, what they accomplish, 
what mistakes they prevent, and what they require from operators 
(both VPN users and service providers) that it makes sense to 
progress both? 

Comments? 

thanks, Ross (and Rick) 

[PS: As Ron is author of one of the documents, for the purposes 
of this discussion Ron will take on the role of document author, 
and let Rick and I co-chair the discussion.]

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Sep 2003 14:18:51 -0400

Ross> The most obvious question is whether we want to progress both 
Ross> drafts separately. In other words, do the approaches differ 
Ross> sufficiently in terms of how they work, what they accomplish, 
Ross> what mistakes they prevent, and what they require from operators 
Ross> (both VPN users and service providers) that it makes sense to 
Ross> progress both? 

I don't think it  makes any sense to progress both drafts.   In fact, as far
as I can tell they are virtually identical from a functional perspective. 

Both of them  seem to protect only against  accidental SP misconfigurations,
neither seems to offer significant protection against active attacks.  

Both work by attaching a new  attribute to the VPN-IP routes.  Actually, one
uses  a  particular  Extended   Community  attribute,  one  proposes  a  new
attribute, but that's hardly a significant difference. 

In both drafts,  the basic method of detecting  misconfiguration is to pass,
with each VPN-IP route, some item (or a function of some item) that is known
to the CE routers.

In draft-ietf-l3vpn-l3vpn-auth,  the item that  is passed around is  a token
that is obtained from a CE router.  This item is passed to other CE routers,
who then verify it.   The token is passed "in the clear";  it is in effect a
cleartext password for the VPN.

In  draft-behringer-mpls-vpn-auth, the  item  that is  passed  around is  an
ordered pair consisting of (a) a random number that has been assigned to the
source VRF of  the route, and (b)  the MD5 hash of that  number, as computed
with the MD5  secret key used in authenticating  the PE-CE routing protocol.
It  seems to me  that this  ordered pair  is pretty  much equivalent  to the
"token" of the  other draft.  That is, it is in  effect a cleartext password
for the VPN.  

In  draft-ietf-l3vpn-l3vpn-auth,  the  cleartext  password that  is  carried
across  the backbone  is  explicitly provided  by  a CE,  and is  explicitly
verified by the other CEs. 

In  draft-behringer-mpls-vpn-auth, the  cleartext password  that  is carried
across the backbone is computed from the secret key known to the CEs and PEs
of a particular VPN (with the assumption  that the secret key is the same at
both ends).

So I think the only real differences are: 

- The token  method requires the CEs to have new  procedures for sending and
  receiving the token. 

- The  token method does  not require  the CEs to  all send the  same token,
  though it does require each CE to be able to verify all of the tokens used
  in its VPN.

- The  MD5 method  doesn't require the  CEs to  have any new  procedures for
  token handling, as long as the CE is already using MD5 to authenticate its
  PE-CE routing exchange.  This is an advantage, but one which disappears if
  there is no MD5-authenticated PE-CE routing exchange. 

- The  MD5 method seems to require  that all CE-PE routing  adjacencies in a
  VPN be keyed the same.  This seems like potentially a large difficulty. 

If seems to  me that even if the  WG wanted to allow both  methods, a single
draft should be  produced, with the PE-PE mechanisms being  the same in both
cases.  I tend to prefer the token method, but this merits more discussion.