Subject: RE: draft-behringer-mpls-vpn-auth-00.txt

From: "David Allan" <[email-masked]>
Date: Tue, 19 Nov 2002 16:43:31 -0500

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

---

From: "Jim Guichard" <[email-masked]>
Date: Tue, 19 Nov 2002 16:55:47 -0500

Hi David,

thanks for the comments - the main reason that we selected MD5 was that it
is generally available (for all routing protocols) and is recommended to
many Enterprises as a 'best practice' for their IGP deployment. The key
(please pardon the pun) advantage of using the MD5 key is that we cannot
receive incorrect routing information from the attached site and therefore
if we misconfigure either the key or the RT, routing information will either
be a) rejected at source, or b) rejected at a remote PE due to key mismatch.
Some further comments below ..

> >consistency check between the CEs and PEs.

yes, but at the routing authentication level ..

> >all boxes, so there is still room for finger trouble.

yes, both the PE and CE require the key to be configured - finger trouble
could still occur but the difference is that the possibility of leaking
information into another VPN due to this misconfiguration is avoided.

I was
> >suggesting a way

but if you derive the key from the configured RT, and the RT as configured
is incorrect, the key becomes irrelevant. Could you explain the flow of how
the RT relates to the key and how this is communicated to the CE ?

Jim