RME: looking for a reliable and secure transport

[g.meerkoetter]

I'm looking for a secure (i.e. stronly authenticated and encrypted)

transport mechanism for software and configuration management in LMS

3.1. Regarding firewalls, this is even a requirement for me, since it

is what our local firewall policy demands.

SCP transport sounds promising, at least for configuration archive and

SW image transfer. Unfortunately it is not supported by Cisco's firewall

devices (ASA, FWSM, and PIX). On IOS devices I've seen that it is

utterly broken - there are ^Ms instead of linefeeds in the archived

files (no, I'm not running LMS on MacOS!) and banner termination

characters get lost, making the following commands look like part of the banner.

SSH would be my next candidate. This sometimes works quite reasonable,

although there's a frightening number of bugs, some of which are still

not fixed. I've hit another one which is not in BugTool, yet. But having

a closer look, I found out that SSH transport may also mean that the

actual data is tranferred using TFTP! IMHO this is a really deceptive

naming scheme. I've also seen that RME tries to use telnet first,

although SSH is the primary transport in my configuration.

So how's my chance to see this mess cleaned up in the next 12 months and

to get a decent transport inplementation conforming to my requirements?

How do others think about this? Am I just too demanding and should I be

happy that there's still telnet support in LMS3.1?

[Joe Clarke]

Part of the problem when it comes to the PIX/ASA is that they don't support SCP as a transport mechanism. So, while we can log in to the device securely to initiate the transfer, we must use TFTP to copy the underlying data.

There is an https alternative (at least in newer code), but that would require some architectural changes to LMS. This kind of change may be possible in the next 12 months assuming the appropriate PER is filed.

As for RME using telnet first before SSH, I have fixed most instances of this. There is one instance left in the security context code which I just tracked down. The code is there to find supported module information. That should be fixable. However, it's not a critical issue as one could just disable telnet on the device to avoid the use of an insecure protocol.

[g.meerkoetter]

Will the broken SCP transport get fixed any time soon?

And would you please post the bug-IDs for that, as well as for the telnet before SSH bug?

[Joe Clarke]

What broken SCP transport? As far as I know, all known SCP bugs in LMS have been resolved. As for the PIX/ASA not supporting SCP as a copy protocol, there is an enhancement bug (CSCso31893) filed, but it is not be available until 8.2(1), so adding RME support for PIX and SCP is probably not going to be too useful.

As for the telnet before SSH bug, I haven't filed it yet. I think there is another, more severe socket leak in the same code, and I am awaiting some debug results before proceeding.

[g.meerkoetter]

As I mentioned in my initial post, config files archived using scp have ^Ms instead of linefeed

characters, and multiline motd banners lack the termination character. The initial ^C obviously gets replaced by a '&' inside the scp transport code.

$ file 133-20090130130701.cfg

133-20090130130701.cfg: \012- Assembler source

$ wc -l 133-20090130130701.cfg

0 133-20090130130701.cfg

$ tr '\15' '\12' < 133-20090130130701.cfg | fgrep "&"

banner exec &&

banner motd &

$ tr '\15' '\12' < 133-20090130130701.cfg | fgrep $( echo \\03 )

I've seen the error on cat6500ios, cat4500ios and 3845 devices, so this looks pretty generic.

Thanks for the enhancement bug ID, so at least there's some hope.

[Joe Clarke]

These files are not meant for direct human consumption. What do the shadow configs look like under /var/adm/CSCOpx/files/rme/dcma/shadow?

[g.meerkoetter]

Sorry, I can't tell that any more, since my snapshots of the shadow directory go back only one week. I have of course immediately disabled the

scp transport when I knew it was defective.

I have attached screenshots which show how I got aware of the missing banner termination character.

[Joe Clarke]

I recreated this, and found that the shadow directory files are good. The banner termination thing is weird. I found code which explicitly replaces '\003' with '&' for RCP and SCP transfers. This goes back all the way to RME 4.0, and I have no idea why they did that. I suspect this was something vestigial that should have been removed in the release.

[g.meerkoetter]

Looks like you spared me another longish TAC SR,

thank you once again, Joe.

Will you be so kind and post the bug ID here?

[Joe Clarke]

Development has said they plan to fix the banner problem as part of the fix for CSCsu99748 in RME 4.3 (due out this summer).

[g.meerkoetter]

I can only speculate on the reason for handling

two seperate bugs under a single ID, but it smells like somebody it misusing the number of bugs as a gauge for software quality...

I'd rather see this distinct bug documented seperately. KISS: One Bug - one ID - one fix.

That's a scheme I can cope with.

Anyway - many thanks for you efforts, Joe.

[Joe Clarke]

I've done ahead and created a patch for the Security Context code which should fix the telnet attempt issue as well as a socket leak. If you open a TAC service request, I can provide the patch if you want to test it out.

[g.meerkoetter]

I'm afraid that might conflict with the other two patches I already have in my xdi.jar. I will discuss that with the owner of my corresponding SR 610239175 next week.

Thanks for tracking this issues down.

[Joe Clarke]

No, the patch does not touch xdi.jar, and will have no effect on my other fixes there.