The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Section 2.9.2 of RFC3036 requires that md5 authentication be
turned on through configuration, on a per/peer basis.

"An LSR that uses the MD5 Signature Option is configured with a
password (shared secret) for each potential LDP peer."

	If you look at existing implementations, you will notice one way
to implement this is to identify the peer by its address. As you
mentioned in your mail, this requires configuration. However, usually one
would use authentication on the untrusted peerings only, so there wouldn't
be a need for a full mesh.

			Ina Minei

On Wed, 21 Aug 2002, Morvan Daniel [iso-8859-1] Müller wrote:

> Hello!
>
> Excuse me about erros, my english is poor :)!.
>
> At 17:18 13/08/2002 +0200, you wrote:
> >LDP Implementation Survey Form [V 1.0]
> >...
> >================+=============================+========================
> >TCP MD5 Option  | 2.9                         |
> >================+=============================+========================
> ...
> >
>
> About "TCP MD5 Option" into LDP I have some doubts about inform locally, in
> each LSR, all possible peers and respective keys, like:
> LSR A local confuguration:
> LDP Authentication Option = enabled
> lsr-peer-idC : md5-keyC
> lsr-peer-idB : md5-keyB
> ...
>
> Considering that "TCP MD5 Option" is a global option on the LSR, i.e., if
> the authentication=ON this LSR only talk with peers who could authenticate
> (know the md5-key), OK?
>
> Consider a mpls domain:
> C
> |
> |
> A--- B ------- E
> |              |
> |              |
> D              F
>
> If you configure A with auth=ON. You need configure B, C and D with auth=ON
> and inform the md5-key, to permit talking between they.
> If B have auth=ON it only could speack with E if it have too auth=ON and
> know the Md5-key, on so on ...
>
> How is the MD5 Auth OPtion implemented in the LSR police:
>
> 1) you could inform that any peer can speak without authenticate and only
> especific peers need authenticate. I think No, is no meaning!
>
> 2) you could identify local domain sessions and permit it, and supply
> authentication for external domain sessions, or indirect (non adjacent)
> sessions? if so, how its possible identify such session? (I think in
> stack-bit, but local domains LSRs can too use label stacking for especial
> situations like traffic eng., etc..)
>
> 3) Ldp authentication is based on the LSR physical interface? So you can
> suplly authentication for specific LSR interfaces (like LERs ingress
> interfaces) and for internal domain interfaces don't supply authentication.
>
> 4) Its necessary configure manually all LSRs in the mpls domain to talk
> with each other, by inform all possible ldp_peers and respective md5-key.
> It will be a problem for scale?
>
> I may miss-understood something in this environment, please coul'd someone
> clarify me?
>
> Thanks,
>
> Morvan.
>