The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] LDP TCP/MD5 Option implementation understanding!
Hi Ina! At 16:30 21/08/2002 -0700, you wrote: > 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." ok. > 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. ok. >However, usually one >would use authentication on the untrusted peerings only, so there wouldn't >be a need for a full mesh. rigth, is a valid and a simple solution. (Police = allow all and deny especific cases). One problem is address spoofing! Thank you very much, Morvan. > > 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. >> > > >
|
|