The MPLS WG Archive

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

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


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

yes, but at the routing authentication level ..

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

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

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