Re: draft-jones-opsec-01.txt comments: in-band management

[ericb@digitaljunkyard.net]

 "jnw" == Joel N Weber, <Joel> writes:

>> If people have suggestions for ways to tie the current
>> implementations more strongly to the requirements
>> without precuding better implemetaionts later, I'm all for
>> it.

List current protocols that "at the time of this writing" met the
requirements, and _why_ they work.

>> I'd love to say "SSH, no telnet", "SNMPv3, no SNMPv1",
>> "SCP/SFTP, no TTP".

Then say "currently, SSH is an acceptable terminal access protocol
(encryption, user auth, host auth, etc), while telnet is not (clear
text, no host auth)."

SSH is then stood up as an example, not as a recommendation or
requirement.

jnw> We can always update the document in five years.  The C in BCP does
jnw> stand for something...

Yeah, but if we can avoid limiting it's lifespan, that's a good thing
too.  If someone find a fatal, fundamental flaw in SSH next week,
despite Theo's rabid security, what are we left with?

jnw> I suspect we can easily get rough consensus that SSH is the only
jnw> widely deployed secure remote terminal protocol, and therefore it is a

Terminal, yes.  What if the device in question is a Cisco VOIP call
manager running on a Cisco that's really an HP that's really a Compaq
running Win2k?  You need a GUI, and forwarding MS Windows over ssh
doesn't quite work correctly yet.

Let the vendors and the users negotiate whatever is acceptable to
themselves.  In this case, Windows Terminal Services over IPSec works
great, as it's a homogenous network.

jnw> Is there anyone who's actually going to object if we mandate that STFP
jnw> and SNMPv3 be available?

sftp or scp?  There are good reasons to run both.  But then, you're
running both terminal access and file movement over the same TCP port.
It's kinda nice to be able to filter them using network devices
seperately.  I've often heard the argument that the device listen on
no file transports at all, and act solely as a client.

I think that requiring "strong" encryption and secure management
channels is sufficient.  Single vendor networks exist, and some people
will be happy running a vaguely standards based IPSec implementation
that does everything that they want.  Other networks will require
better interoperability, and require more standards based protocols.
I think that comes down to an issue between the customer and the
vendor, not the standards body and the vendor.  Neither path leads to
greater security.

ericb