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