Subject: Re: TCP MD5 Signature Option Unsupported in Ldp MIB

From: Hans Sjoestrand <[email-masked]>
Date: Thu, 25 Nov 1999 10:22:22 +0100 (MET)

Hi,

> From [email-masked] Wed Nov 24 19:20:09 1999
> 
> 	Hi,
> 
> 	It appears as though the LDP MIB (v-03) does not
> currently include any support for the configuration and monitoring
> of the MD5 Signature Option (section 4.1 in the LDP Specification).

to true. But thats more an oversight than intentional. 

> Chapter 9 of the LDP MIB, entitled, "Security Considerations"
> only makes mention of security in terms of SNMP. 

"Security Considerations" discusses the security implications of
supporting thet mib, not the protocool that is managed. Adding of
object to manage MD5 signatures does not impose any additional treat
than supporting read/write object in general in my mind. 

> Is this in the
> works, or should I or someone else make a proposal for how to
> make these additions to the MIB?

Proposals to meet the requirements in sec 4.2 of LDP Specification 
are very welcome. I also guess that with "monitoring" you mean that 
you wan't some additional stats object(s) aswell?

Regards
/// Hasse

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 Nov 1999 09:50:57 -0500

>are very welcome.

         Excellent. I will work out a proposal for adding this information
to the MIB and mail it out on Monday.

>I also guess that with "monitoring" you mean that

         Yes, it might be helpful to note the number of security violations,
etc... so that the operator might be able to detect misconfigured or
unwelcomed LSRs which are attempting to connect to it.

         --Tom

---

From: Joan Cucchiara <[email-masked]>
Date: Mon, 29 Nov 1999 11:07:35 -0500

Tom,

It is probably useful to have counters for security related
events, however,  I see very little benefit of configuring passwords
into a MIB
in general, and this MIB in particular since the security feature
is optional and does in my mind introduce an unnecessary risk to the
protocol.

I'd prefer to add some "hints" of what folks could add to
their enterprise MIBs if they really want to configure passwords
via the their MIB.  This could be added to the security section
of the MIB.  MIBs should not make a protocol less secure, and 
I believe that adding passwords to this one does.

	Thanks, Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 29 Nov 1999 14:15:03 -0500

Hi,

 >into a MIB  in general,

         On the contrary, I see lots of benefit in allowing for
all configurable parameters to be available in the MIB. The
main reason is consistency for the system manager. By
effectively mandating that these parameters exist in a proprietary
form, you may in fact confuse the issue. For example, if vendor X
decides that the best way to configure LDP in their proprietary MIB
is using method X, while vendor Y does it another way, method Y,
then the manager needs to understand more configuration information.
The managers I know do not enjoy having additional configuration information
to learn. ;) Furthermore, by taking this approach, you are effectively 
requiring
that the NMS used by said manager whose network has devices from vendor
X and Y understand both, perhaps very different, configuration mechanisms.
As we all know, multi-vendor support by many NMS systems is not
always as timely or as consistent as we would like. :)

 >and this MIB in particular since the security feature

         One option would be to add the passwords, etc... but
instruct the implementations to optionally ignore them if
they feel they are too insecure for their tastes. The operative
words here are "their tastes". The implementation can optionally
ignore security information if the "enable LDP security" knob is
disabled, or if the SETs come from unauthenticated sources.
That is, I would strongly recommend that the use of LDP security
configuration should go hand-in-hand with the security mechanisms
of V3 if the configuration features are to remain secure.

         I think by not allowing these features to be in the MIB,
you are actively constraining the configuration by imposing
the security policy that "we will not allow you to configure
security because *we* know better and think it is unsafe,
so you had better not use it. " If the administrator feels that
allowing the configuration of such variables is too unsafe for their
tastes, then the administrator  can disable the feature by pushing
the "disable LDP security" knob and/or  properly configuring SNMP
V3 security. However, we should assume that the administrator know
how to configure LDP and V3 security features. We made this
assumption with other changes made to this MIB recently, so I think
that we should be consistent, and make the same assumption now
as well.

         --Tom

---

From: Joan Cucchiara <[email-masked]>
Date: Mon, 29 Nov 1999 19:49:51 -0500

> so you had better not use it. " If the administrator feels that

The above statement is a harsh.  I did NOT imply this sentiment, nor
do I believe it.  I said that configuring passwords via a MIB
for LDP's TCP connections introduces risk. 
Particularly with this protocol because you'd
have to go configuring passwords on the LSR and some number
of its peers and then some of their peers and so forth.
And you would "probably" also have to retrieve passwords from the
peers via the MIB in order to have a MIB solution which was
thorough.

I believe that configuring and/or retrieving
the passwords in other ways (i.e. not setting/getting them via MIB
objects) 
is less risky.  

As for interoperability, the argument you present seems contradictory.  
A vendor is free to either support configuring passwords via the MIB or
not (i.e.
"their tastes") but yet, a vendor which does do this will need to know 
what its peers passwords are, so if the peers do NOT wish to 
have their passwords available for retrieval in
the MIB, then the vendor who is using the MIB is out of luck, or needs
to
find out the peers' passwords some other way.   

Last but not least, unless one could ensure that the
LSP was using this security option that having it exist between 
a few peers is probably not too effective.  In other words, it would 
require that passwords be configurable via the MIB throughout the
LSP, for the MIB to reallly be effective.  If this is what is intended
then
this is out of scope for the LDP MIB. 

I also checked on BGP4 MIB (although in draft) and did not see
any means of configuring the TCP Password via the MIB.  Likewise with
the TCP Connection tables in the IPv4  (rfc2012) and 
IPv6 (rfc2452) versions are not configuring passwords via the MIBs.  
Why should the LDP MIB provide objects for configuring TCP passwords, 
when TCP and BGP do NOT?

Again, I would certainly prefer that configuring/retrieving these
passwords be discussed under the security section and NOT put in the
standard MIB. Feedback from other vendors would be appreciated on this
issue.

        -Joan