[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

I had been wondering whether it would be possible to recommend a default IPsec profile for in-band management traffic to make it more probable to have something usable and interoperable. Something along the lines of requiring the use of IKE (I recently came across an issue where a router vendor had a great BGP IPsec authentication implementation but could only do manual keying....yuk). Parameters to use could be:

IKE Phase 1:
Main Mode
3DES
SHA
DH group 2
Lifetime (what's reasonable....a day?)
pre-shared key authentication

IKE Phase 2:
3DES
SHA
DH group 2
PFS
Lifetime (what's reasonable....8 hours?)


There might then be a hope if someone just has to set the pre-shared secret, remote IP peer and define a filter for the traffic selector (telnet, snmp, tftp, etc) that IPsec would actually work.

However, this gets into the same problem as George had for defining 'strong' encryption algorithms. Should we specify 3DES or AES.....3DES used now but once more implementations have AES that will probably be more commonly used. Also, IKE v1 or v2.....although from what I've heard v2 is more a checklist than something vendors will seriously implement.

Anyway...I thought I'd put it out there. In any event, I would agree with Joel though that if we skip the IPsec 'recommended' profile then it would be useful to be more specific in how management traffic would be secured so that it's practical.

- merike

At 11:53 PM 10/22/2003 -0400, Joel N. Weber II wrote: 
I wonder if it would make sense to explicitly mandate specific
encryption protocols for in-band management protocols.  For example,
for devices that support an in-band CLI, we could require sshv2.
There's a specific IETF-standardized secure syslog protocol, and
perhaps devices should be required to implement that.  I think some
version of SNMP gains certain sorts of security guarentees (though
perhaps not all the security guarentees one wants, but debating that
is beyond the scope of opsec), and perhaps implementing that should be
mandated.

Part of what I'm concerned about is that it would be easy to write the
opsec document such that good old telnet, run on top of IPsec, would
meet the requirements for secure in-band management.  I'm not sure
that that's actually all that useful though; I don't think I've ever
met anyone in the real world who's claimed to succeed at getting two
IPsec implementations that don't share a common source base to
interoperate usefully, and every now and then I talk to friends who
have just as much interest in switching from PPTP to IPsec as they did
a few years ago, if only they could figure out how to make IPsec work.

But the other thing is that it seems like if I have a laptop computer
with a usb to rs-232 adapter, and an RJ-45 ethernet port, and some
basic set of software, and the right collection of ethernet and serial
cables, that ought to be sufficient to manage any arbitrary network
device.  If there aren't several separate implementations of adaquate
software based on separate code bases, then it probably isn't really
all that standardized and non-proprietary...