Subject: RE: LDP TCP/MD5 Option implementation understanding!

From: "Gray, Eric" <[email-masked]>
Date: Wed, 21 Aug 2002 18:53:55 -0400

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.
[email-masked]
508 305 7214

-----Original Message-----
From: Morvan Daniel Müller [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2002 6:35 PM
To: [email-masked]
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.

---

From: Morvan Daniel Müller <[email-masked]>
Date: Thu, 22 Aug 2002 00:50:48 -0300

Hi Eric!

>TCP MD5 Signature option for those interfaces.

Ok, it clarified!

Thank you very much!