> IMO it would be best to make it a MUST that the flags
> may only be sent as the last element. What rationale is
> there for putting it anywhere else?
In the event that there are two or more competing extension mechanisms, only one of them can be last.
> and don't "replace" any messages like
> SSH_MSG_SERVICE_REQUEST.
But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :)
Does no one agree that SERVICE_REQUEST + ACCEPT are pointless?
A whole round-trip delay? For no benefit - in any known usage scenario?
> OpenSSH has sent various @openssh.com global
> requests for years, so most of the implementations
> that violate this should have long since been shaken out.
Do you happen to know:
- Since which version the OpenSSH server has been sending global requests?
- Since which version the OpenSSH client has been tolerating them?
There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sure I saw our software being connected to by a client like that in the past week.
> (e.g. it's impossible to have one channel without the
> "handbrake" and one with normal flow control)
As discussed, this is on purpose. If you want multiplexing, implement multiplexing, including flow control.
If even one channel does not have flow control, this affects the transport layer also. It affects keep-alive mechanisms, key exchange, and flow control at the transport level.
> Given this, IMO this would be better off being replaced by a
> generic "these are the channel types I'm prepared to open"
> message, which would be useful even for implementation
> that don't want to turn off flow control but which do
> implement non-standard channel types (e.g.
tun%openssh.com@localhost).
Sounds like an idea for another extension:
Name: supported-channels
Value: name-list of accepted channel types
? :-)
denis
----- Original Message -----
From: Damien Miller
Sent: Wednesday, December 2, 2015 05:35
To:
ietf-ssh%netbsd.org@localhost Subject: Feedback on draft-ssh-ext-info-00
Hi,
Here's some feedback on draft-ssh-ext-info-00.
> 3.1. Signaling of Extension Negotiation in KEXINIT
...
> The indicator name is added without quotes, and MAY be added at any
> position in the name-list, subject to proper separation from other
> names as per name-list conventions. The suggested position is last in
> the list, but implementations MUST recognize these indicator names
> when included at any position.
IMO it would be best to make it a MUST that the flags may only be
sent as the last element. What rationale is there for putting it
anywhere else?
> 3.2. Mechanism Enabling Criteria
This whole section seems over-complicated. I think a simpler scheme
is:
If a client or server offers "ext-info-c" or "ext-info-s" respectively,
then it must be prepared to accept a SSH_MSG_EXT_INFO message from the
peer.
If this message is sent, then it will be the first message after the
initial SSH_MSG_NEWKEYS.
I.e. make it a simple advertisment that a client or server is willing
to accept a notification message that might optionally be sent.
Don't require both sides to offer acceptance, don't have the messages
offer any sort of negotiation between the client and server (just
statements of extensions/capabilities) and don't "replace" any
messages like SSH_MSG_SERVICE_REQUEST.
This would yield a much simpler specification IMO.
> 4. Initially Defined Extensions
> 4.2. "client-req-ok"
I don't see the point of this: implementations that don't respond with
SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are
incompliant with RFC4254 section 4.
OpenSSH has sent various @openssh.com global requests for years,
so most of the implementations that violate this should have long since
been shaken out.
> 4.3. "no-handbrake"
This could be implemented more elegantly using new channel type names
in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and
inflexible method proposed here (e.g. it's impossible to have one
channel without the "handbrake" and one with normal flow control).
It would be better to use the extension to signal that the
peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel
type names, and use these to selectively disable flow control.
Given this, IMO this would be better off being replaced by a generic
"these are the channel types I'm prepared to open" message, which would
be useful even for implementation that don't want to turn off flow control
but which do implement non-standard channel types (e.g.
tun%openssh.com@localhost).
-d