On Sat, 12 Mar 2016, Donald Sharp wrote:
No? :)
It's not clear to me at all that:
(a) allot of people use telnet over vtysh
There are some people offering public telnet access to bgpd - and others
who maintain lists of these public route-servers. Also, there are
"looking glass" scripts, and these often use telnet (even as IPC) as
that's the common denominator protocol.
(b) that they've read the code to know that there is a restricted
functionality that only exists for bgp
If someone has played with the telnet interface, they'll have probably
tab-tabbed under the 'line vty' configure node and seen the command,
which is fairly self-documenting:
"Restrict view commands available in anonymous, unauthenticated vty"
So if they know about the anonymous, unauthenticated mode, they very
likely know about this - and the public servers I found either have it
enabled or hacked something similar in themselves.
(d) that people are logging in and only giving themselves limited
permissions
Existence proofs seem to exist - google for public route-servers. We'd
break at least a few route-views interfaces. Whether those interfaces
are used, I don't know. You could contact them.
(e) that we are not working towards fixing performance issues that are
listed as a main cause of needing this functionality.
Table dumping commands are intrinsically going to incur higher costs
than query commands.
1 small message out - *lots* of output back, unbounded in size at least
relative to size of the original message
vs
1 small message and 1 relatively constant factor times size message
back.
Even if table dumping is efficient, you might still want to limit it,
just based .
Anyway, I think restricted and anonymous vty go together. I just
couldn't make restricted the default for the latter as I couldn't know
who was using anonymous vty for what - but I suspect 'restricted' is
what most want. However, if restricted is removed the other should be
too.
That said, you could remove the anonymous telnet login mode, and even
the telnet support, but still want to maintain a list of low-risk
"query" commands and assign them to a common group/node.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"If we were meant to fly, we wouldn't keep losing our luggage."
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
