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

["Greg Sayadian" <gsayadian@aol.com>]

I would not recommend trying this.  Although these algorithms have been 
standardized and have been in use for a long time, in practice each 
vendor does things their own way.  In a homogeneous environment IPSec 
works great, but as soon as you go into a heterogeneous environment 
things break, more so with IKE than manual key but the pains of getting 
two different vendors to play well with IPSec is difficult to say the 
least.

The reason I bring this up is that most people have their own inhouse 
method of managing their network and would need to implement their own 
(most likely freeware) way of connecting to the device via IPSec.  It is 
inevitable that the vendor would provide their own vehicle to manage 
their devices that would cost the customer more money and pain in 
submitting bug reports for the software trying to get it to work.

just my $0.02

Merike Kaeo wrote:

 > 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...
 >
 >

-- 
<><
Greg Sayadian
AOL Network Security
(703) 265-2483