The MPLS WG Archive

["Jim Guichard" <jguichar@cisco.com>]

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:dallan@nortelnetworks.com]
> >Sent: Friday, November 15, 2002 10:18 AM
> >To: Michael H. Behringer; jguichar@cisco.com
> >Cc: mpls@UU.NET
> >Subject: draft-behringer-mpls-security-03.txt
> >
> >
> >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.

correct

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

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
> >level of indirection (two provisioned values to get right at the
> >PE) in the
> >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
> >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 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

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