Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jul 12, 2011 at 04:24:18PM -0700, Kent Watsen wrote:

> And now, without further ado, here are the four possible solutions:

[...]
 
> How to move forward?
> 
>    - first, it would be interesting to get some feedback on the various
>      proposals from the NETCONF and OPSAWG WG members.   I realize that
>      above are very high-level descriptions, but hopefully it's enough
>      to get the gist of what's being proposed...
> 
>    - if it turns out that there is significant support for solution #1
>      (or even #2),  then we might be able to take that back to the SAAG
>      and IETF-SSH lists for their reconsideration.  Alternatively, perhaps
>      either the OPSAWG or the NETCONF WG would be interested in picking
>      up this I-D?  As a last-ditch effort, would it make sense to submit 
>      it as an EXPERIMENTAL RFC? - would others who asked for this draft
>      to be submitted even implement an EXPERIMENTAL RFC?

There is some history of this discussion in the ISMS working group.
When ISMS did SNMP over SSH, we had a hard time dealing with
notifications and the Juniper approach was already put on the table at
that time as "running code that seems to work in practice to solve an
operational problem". As far as I recall, there was no doubt about the
operational problem and the need to solve it _but_ there were security
concerns brought forward. I would have to do several hours of reading
of ISMS archives in order to phrase them correctly. But simply put (as
far as I recall - and I don't really recall any details and so I might
be totally off), the concern had to do with something not truely
authenticated to tell a box to SSH somewhere which involves the usage
of identities with cryptographic keys. In ISMS, we ended up making the
notification originator the SSH client - and this caused quite some
costs since the amount of config increases and the identity to bind
access control to becomes different.

So in essence, I believe we have been for years at a deadlock
situation where operational people were clear that a solution for
devices to "call home" is clearly needed but the security people had
security concerns with the solutions presented and the solutions liked
more by security people to be operationally a pain. 

Perhaps one path forward is to have the operational people push a
solution that is implementable and solves an operational problem
(without creating a new operational problem) through the whole IETF
process forcing the security people to clearly document their security
concerns and then it can be seen whether that text all goes into the
Security Considerations and the protocol passes or the document stops
at the IESG. This is potentially a painful exercise.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>