Henrick Hellström <henrick%streamsec.se@localhost> writes:
Niels Möller wrote:
I think, quite strongly, that such substructure should be out of scope
for the core drafts.
Fair enough, but I suggest that there at least should be stipulated in
the specification that locally assigned disconnect codes MUST NOT be
sent by standard protocol features.
Right, locally defined numbers should not appear on the wire unless
you have somehow agreed with the receiver what they should mean.
One example where that can be used safely on the wire, is if you
receive a CHANNEL_OPEN request for some locally defined channel type
"foo-channel%lysator.liu.se@localhost", then you can safely reply with a
CHANNEL_OPEN_FAILURE and any locally defined reason code associated
with the specification for that channel type.
The appropriate way to avoid such situations ought to be to stipulate
that locally assigned disconnect codes must only be sent by locally
specified protocol features (e.g. keyestablishment@host,
subsystem@host etc).
That is sane advice. But it is also an important part of the idea of
the locally assigned numbers, that you are allowed to use these
numbers in anyway you please, as long as you know what you're doing,
and don't expect interoperability with other standards compliant
implementations.
The easiest way to sum this up is to say that use of locally defined
numbers is *not* standardized in any way, that they can be used only
under prior agreement between the involved ssh installations, and that
any agreements on how they are to be used are out of scope for the
specification. Is there some standard phraseology for this? It's
surely not unique for ssh.
Regards,
/Niels