Subject: draft-behringer-mpls-security-03.txt

From: "David Allan" <[email-masked]>
Date: Fri, 15 Nov 2002 10:18:06 -0500

Michael/Jim:

If I understand the problem you are addressing correctly, it is incorrect
configuration of the RT associated with a CE at the PE. And you wish to do
this with no changes to the CE, therefore you are re-using the HMAC/MD5
stuff to achieve this.

What you actually want is the RT configured at the CE and a means of
checking that there is consistency between the CE and PE. IMHO adding a
level of indirection (two provisioned values to get right at the PE) in the
network will not achieve this.

What I would suggest is that you keep the HMAC/MD5 approach for CE-PE, but
have the key configured into the CE algorithmically derived from the RT
associated with the VRF (or from the set of RTs in more complex
configuration cases). Therefore there is still typically only one value to
provision at the PE for the CE (the RT, which is the one that matters). You
are not using multiple values across the core (HMAC MD5 and RTs, you only
need RTs) so no BGP changes are required, this is purely a S/W issue at the
PE. 

The only issue I can see is that in the more complex VPN cases (hub and
spoke/extranet etc.), there is not one key for all CEs, (e.g. hub site is
different key than a spoke site or extranet issues). This seems like a small
price for no protocol changes and actually closing the hole. Besides I
believe a CE can belong to more than one VPN therefore without this approach
there is still a gaping head wound as it can only verify membership in one
VPN.

cheers
Dave

---

From: "Jim Guichard" <[email-masked]>
Date: Tue, 19 Nov 2002 15:18:22 -0500

Hi David,

sorry for the late response but I have been travelling ..

first off, the draft we are talking about is
draft-behringer-mpls-vpn-auth-00 and not draft-behringer-mpls-security-03 (I
am not a co-author of this draft and have no involvment with it).

second - the draft which is posted at the ietf website is the incorrect
version and was posted in error - I have the correct version sat here on my
laptop but have been unable to re-post until after ietf - I will do this
next week.

Some comments below ..

> >-----Original Message-----
> >From: David Allan [mailto:[email-masked]]
> >Sent: Friday, November 15, 2002 10:18 AM
> >To: Michael H. Behringer; [email-masked]
> >Cc: [email-masked]
> >Subject: draft-behringer-mpls-security-03.txt
> >
> >
> >Michael/Jim:
> >

correct

> >checking that there is consistency between the CE and PE.

currently the RT belongs to the SP and is maintained/provisioned by the SP -
the customer has no involvement or knowledge of this process. Theoretically
the customer could tell the SP the RT value it should use for its VPN but
then this would be subject to a) overlap with other VPNs & b) difficult to
implement into the existing provisioning platforms. This means that the SP
would have to tell the customer which RT value to use, which they might get
wrong and we are back to square-one.

IMHO adding a
> >network will not achieve this.

well it will if the customer provides the key and then routing is
authenticated using this key across the SP to customer connections.

> >
> >What I would suggest is that you keep the HMAC/MD5 approach for
> >CE-PE

in which case the PE must still be configured with a key to facilitate
routing authentication.

, but
> >need RTs) so no BGP changes are required, this is purely a S/W

the correct draft specifies that an ingress PE uses a 'generator' value
(which is a random number at the PE) and creates a signature by using the
key against the 'generator'. The result of this operation is carried within
BGP so that a receiving PE can run its local key against the 'generator' and
compare the result with the signature that was created by the originating
PE. Jim