[dropping NANOG]
On 6-sep-2005, at 20:43, Eliot Lear wrote:
I consider the fact that random people across the internet can't
manage
my equipment a feature rather than a bug.
Use of a well known port that you can block will actually make it
EASIER
for you to make use of that "feature". Today if you leave your PC up
with various forms of commercial software, you have no idea who is
connecting to what.
Ok.
The IETF has been doing extensive work on NAT traversal, have a look
and see if you can reuse some existing mechanism.
All mechanisms used with the possible exception of an additional SNMP
table will be re-used from existing IETF work (mostly SSH with help
from
the fact that it's based on TCP).
You do realize that you import all the weaknesses of TCP then, don't
you?
I'm not too familiar with NAT traversal techniques, but AFAIK there
isn't a good match between these mechanisms and what you want to do
here. You may want to consider looking at the mechanism for HTTPS
proxying. This works by having the client connect to the proxy,
optionally authenticating itself, and then asking the proxy to
connect it to the ultimate destination. The encryption is end-to-end
and thus opaque to the proxy, but the proxy does have the opportunity
to assert access restrictions. You'd probably need a mechanism for
internal to-be-managed systems to register their manageability with
the proxy.
A simple split horizon (in addition to the normal layers of access
control) could avoid these proxies from being abused for spam and the
like.
Obviously the SSL in HTTPS is a bit different from SSH, but that
shouldn't be too hard to fix one way or another.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf