The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi Jim:

Thanks for replying, apologies for confusing the two drafts. Replies in
line....


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

You misunderstand me. I assume the RTs are service provider administered.
What I understand the draft is proposing is a mechanism of having a
consistency check between the CEs and PEs.
> 
> 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 interpreted this to require was some additional token provisioned in
all boxes, so there is still room for finger trouble. I was suggesting a way
to minimize finger trouble by having the token provisioned into the CE
provided by the service provider and derived from the RT. If they still got
it wrong......

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

Which is derived from the RTs associated with the VRF. That way the only
additional configuration step is at the CE.

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

I'll have to look at the revised draft. My original take was that the goal
of the draft was to provide a mechanism to ensure consistency between PE/VRF
and CE with repsect to VPN membership. PE to PE consistency was achieved via
correct configuration  of RTs and whatever inter-PE security mechanism you
chose to employ. 

cheers
Dave


<snipped to end>