Re: WG Chair nits for draft-ietf-secsh-break-00.txt

["Phillip Remaker" <remaker%cisco.com@localhost>]

>  1) security considerations section is missing.

I would think that the main security considerations are:

- Denial of service based on a long duration break.  Should be addressed on
the server side
- Unauthorized parties sending break.  Should be addressed by SSH security
freamework.
- There is no means in the protocol to make certain users able to view, but
not send break.  This is optionally addressed on the server side, based on
authentication credentials.  The protocol need not be concerned.
Unauthorized break requests should be treated as if the server does not
support break.

Anything else?  Should we fold all that in?

> s-c fodder:
>
>  Because "break" is typically used to enter low-level administrative
>  or debugging functions, implementors of this extension SHOULD provide
>  a mechanism to control whether this extension is accepted, and
>  administrators should use care when deciding whether to enable this
>  feature.

>  3) no mention of what to do when the thing on the other end isn't
>     (directly) connected to a traditional serial line.  I'm in favor of
>     saying "MAY implement functionally similar implementation-defined
>     behavior".
>
>     examples:
> - a ssh-to-telnet gateway could convert into the equivalent
> telnet option.
> - a service processor providing remote console access may use some
> other out-of-band signal to the system it manages rather than
> the traditional BREAK..


OK, excellent.  I like those examples.