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 Eric! > If you can configure a different "secret" for >each interface, then you probably could configure >no secret for some interfaces, thus disabling the >TCP MD5 Signature option for those interfaces. > > Does this help? Ok, it clarified! Thank you very much! At 18:53 21/08/2002 -0400, you wrote: >Morvan, > > The TCP MD5 Signature option works at a level >below TCP. In many cases, the option is enabled by >providing a "secret" to the TCP stack (possibly via >ioctl, for example). The extent to which this will >apply - i.e. to interfaces or to the entire LSR - >depends on your implementation (in particular how >TCP is bound to specific interfaces). It is not a >good idea to have a single "secret" apply to every >interface in an LSR. If this were done generally, >or even often, the secret would be quite out in the >open since many LSRs would end up using the same >"secret" for all of their interfaces - forcing the >same "secret" to be shared by a lot of LSRs. > > If you can configure a different "secret" for >each interface, then you probably could configure >no secret for some interfaces, thus disabling the >TCP MD5 Signature option for those interfaces. > > Does this help? > >Eric W. Gray >Systems Architect >Celox Networks, Inc. >egray@celoxnetworks.com >508 305 7214 > > >-----Original Message----- >From: Morvan Daniel Müller [mailto:morvan@softplan.com.br] >Sent: Wednesday, August 21, 2002 6:35 PM >To: mpls@UU.NET >Subject: LDP TCP/MD5 Option implementation understanding! > >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. >
|
|