Re: ISMS working group and charter problems

[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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf