Subject: Re: Message Numbers and Disconnect Codes

From: Martin Forssen <[email-masked]>
Date: Fri, 24 Sep 2004 07:58:03 +0200 (CEST)

On 23 Sep, Joseph Galbraith wrote:
> As for the ranges, with a 32 bit address space, 16 codes seems
> a bit stingy... I'd be tempted to say if the high bit is set
> is locally assigned; however, I do not feel strongly about it.

I agree that 16 seems a bit small. But reserving half the space is
probably overkill. How about making 0xFF000000-0xFFFFFFFF locally
assigned?

	/MaF
-- 
Martin Forssen <[email-masked]>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB

---

From: Henrick Hellström <[email-masked]>
Date: Fri, 24 Sep 2004 08:54:12 +0200

> probably overkill. How about making 0xFF000000-0xFFFFFFFF locally

Please also note that "locally assigned" can (and probably must) be 
defined. There are at least three levels that have to be accounted for:

1. The SSH library. It might contain custom extensions that need their 
own error codes, such as key establishment schemes defined in accordance 
with SSH-ARCH on the name@host form.

2. The application software. The application server might for example 
implement application specific sub systems that in some circumstances 
have to send error codes over the SSH transport level.

3. The specific host

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 10:51:56 +0200

> defined. There are at least three levels that have to be accounted for:

I think, quite strongly, that such substructure should be out of scope
for the core drafts. It would be quite a lot of work to sort the
details of that out properly, and I don't see any huge win in doing
that work. And it's way too late to introduce entirely new concepts
into the specification.

Also note that we are primarily concerned with the protocol on the
wire; how protocol constants are used or misused inside a host is
mostly out of scope.

> 1. The SSH library. [...]
> 2. The application software. [...]
> 3. The specific host

My understanding of "locally assigned" numbers is: Use of locally
assigned numbers is purely an implementation and configuration issue
of the local ssh implementation. The phrase "local ssh implementation"
includes *all* software that speaks the ssh protocols, no matter how
that body of code is divided into libraries and applications.

If you write an ssh library, you are free to reserve some subrange of
the locally assigned space for the library's internal use, and leave
the rest for use by applications (I don't see how locally defined
constants are useful for the library or application, but I imagine you
see some use for it).

That subdivision will then be a part of your library API. If you want
to standardize that subdivision, the right place would be a ssh
library API specification. Which would most likely be of informational
status rather than standards track.

You may of course get into conflicts with other implementation that
uses locally assigned numbers differently. But that's the entire point
of the locally assigned numbers; to allow for some local uncoordinated
experimentation, without interoperability concerns. Whenever you want
interoperability on the wire between different implementations, the
right thing to do is to allocate a new standard number.

Regards,
/Niels

---

From: Henrick Hellström <[email-masked]>
Date: Fri, 24 Sep 2004 11:36:40 +0200

Niels Möller wrote:
> 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.

A situation where Sue sends a local disconnect code 0xFF000000 to Carol, 
  but Sue and Carol do not assign the same meaning to it, should never 
occur.

(Note: A similar problem occurs in e.g. TLS. The cipher suites 0xFF00 to 
0xFFFF are application specific, but there is no way for the peers to 
tell each other if they share the same implementation.)

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). This should entail that Sue will only send a specific local 
disconnect code to Carol, if Carol has already told Sue that she 
supports the locally specified protocol feature that assigns the code.

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 13:07:45 +0200

> 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
"[email-masked]", then you can safely reply with a
CHANNEL_OPEN_FAILURE and any locally defined reason code associated
with the specification for that channel type.

> 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

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 24 Sep 2004 04:48:58 -0700 (PDT)

Hi,

> surely not unique for ssh.

I can specify the term "Private Use" from RFC 2434:

   Private Use - For private or local use only, with the type and
           purpose defined by the local site. No attempt is made to
           prevent multiple sites from using the same value in different
           (and incompatible) ways. There is no need for IANA to review
           such assignments and assignments are not generally useful for
           interoperability.

           Examples: Site-specific options in DHCP [DHCP] have
           significance only within a single site.  "X-foo:" header
           lines in email messages.

If this is OK with everyone, I can make global changes to the documents to
reflect that the use of the term "local use" is consistent with this
definition from 2434.

Thanks,
Chris

---

From: Henrick Hellström <[email-masked]>
Date: Fri, 24 Sep 2004 13:39:45 +0200

> and don't expect interoperability with other standards compliant

No "but".

If you don't expect interoperability with other standards compliant 
implementations there is no reason to restrict yourself to using the 
range of locally assigned numbers in the first place.

The only reason for specifying a STANDARD way of adding locally defined 
codes and features to an implementation, is to make it possible for 
STANDARD implementations to inter operate even if they do not implement 
the same locally defined extensions.

Without this rationale there is little reason to reserve a space for 
locally defined codes.

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 14:50:07 +0200

Henrick Hellström <[email-masked]> writes:

> The only reason for specifying a STANDARD way of adding locally
> defined codes and features to an implementation, is to make it
> possible for STANDARD implementations to inter operate even if they do
> not implement the same locally defined extensions.

I disagree. The primary reason for reserving a space for locally
defined names and numbers, is to make it possible to define your own
experimental names and numbers without getting into conflict with
future *standardized* features. This applies to protocol design in
general. There are no guarantess that your local stuff doesn't collide
with somebody else's, unless you somehow agree about it case by case.

In the ssh protocol, we have a way to define *names* in a way that
gives everybody his own namespace, which makes the situation a little
better (but also more complex) than for many other protocols. But we
don't do that for the numbers in the protocol, and it's not feasible
to do so either, imo.

If you feel strongly that reason codes or other numbers in the
protocol need separate namespaces for local extensions, then the right
way to do that is to replace the numbers with names, using the
extension mechanism we use for all other names. But it's too late for
that, imo, so I'll try to stay away from arguing about such a change
in detail.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 15:01:03 +0200

> reflect that the use of the term "local use" is consistent with this

Sounds right to me. (The text describing private use misses the common
case where a private use identifier is used across sites, by private
agreement, or by convention of some application. A simple example is
the email header "X-Debian-PR-Package:" header that is used all over
the world, for email to and from the debian bug tracking systems. But
we can't really do anything about that).

Regards,
/Niels

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 24 Sep 2004 09:51:34 -0600

> reflect that the use of the term "local use" is consistent with this

This sound excellent to me.

If we wanted to do anything in addition, I would simply suggest
that implementations use the private range values by negotiating
through a private @domain ssh extensions, and that it may be
possible to avoid collision in values between unrelated
extensions by also negotiating the value, i.e., using a
global request message to ask the server to assign
a range of 10 values not used by anything else the
server supports.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 24 Sep 2004 10:25:01 -0600

> with the specification for that channel type.

This example implies that in the channel_open / channel_open_failure
case we may want three ranges:

0x0000 0000 - 0xFDFF FFFF        IETF / connection layer

0xFE00 0000 - 0xFEFF FFFF        channel-type specific, numbers from
       this range for channel-types with @domain in their names are
       defined by the maintainer of the @domain.  For channel-types
       without an @domain are defined by IETF action, and these
       numbers are allocated by IANA.  This registery is currently
       empty for all IETF defined channel-types.

0xFF00 0000 - 0xFFFF FFFF        private range, used any way
       implemention wants, may not interoperate with other non-standard
       implementations, but will never conflict with a standard
       implementation.

The disconnect messages don't have this third range because
they aren't scoped by an extensible name.

- Joseph

PS. For simplicity, I still like just using a bit mask:

The high order two bits scope the reason code; the
following scopes are defined:

00 - IETF / connection layer reason codes
01 - Reserved for future use
10 - Channel-type specific
11 - Private range

Again, when we are talking about a billion reason codes,
I don't think we need to worry about any scope running
out!

But I'm not going to argue to hard for this.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 24 Sep 2004 12:36:49 -0400

>        implementations, but will never conflict with a standard

Good, except we shouldn't set an allocation policy for the 
channel-type-specific range.  It is up to the channel type to define the 
meaning of these values and to establish a registry if one is appropriate 
(I expect it will frequently not be needed, just as we don't establish 
separate registries for the method-specific message type ranges).

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 24 Sep 2004 10:49:53 -0400

On Friday, September 24, 2004 15:01:03 +0200 Niels Möller 
<[email-masked]> wrote:

>> If this is OK with everyone, I can make global changes to the documents
>> to reflect that the use of the term "local use" is consistent with this
>> definition from 2434.
>

Yes, this is definitely the right approach; it's what the "Private Use" 
allocation policy was meant to be used for.

I also agree that reserving only 16 codes for site-local use is kind of 
silly given the size of the namespace.  Martin suggested reserving the top 
1/256 of the namespace (0xff000000 .. 0xffffffff), which seems reasonable 
to me.  However, I would suggest also reserving the values 0xf0 .. 0xff, 
since we have said for some time that those values would be reserved and 
they may already be in use somewhere.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: [email-masked] (Niels Möller)
Date: 24 Sep 2004 22:59:02 +0200

>        implementations, but will never conflict with a standard

I'm not sure this really is needed, but I agree it makes sense.

Regards,
/Niels

---

From: Henrick Hellström <[email-masked]>
Date: Sun, 26 Sep 2004 21:08:30 +0200

Jeffrey Hutzelman wrote:

>> This example implies that in the channel_open /
>> channel_open_failure case we may want three ranges:
>> 
>> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific, numbers
>> from this range for channel-types with @domain in their names are 
>> without an @domain are defined by IETF action, and these numbers
>> are allocated by IANA.  This registery is currently empty for all
>> IETF defined channel-types.
>> 
> channel-type-specific range.  It is up to the channel type to define
> the meaning of these values and to establish a registry if one is 
> appropriate (I expect it will frequently not be needed, just as we
> don't establish separate registries for the method-specific message
> type ranges).

Right, but at a minimum the RFC should state that channel-type specific
numbers or private numbers MUST NOT be sent unless a channel with
@domain in its name has been requested.

The same restriction should be applied to disconnect reason codes: They 
MUST NOT be sent unless the peers have previously negotiated a domain 
specific protocol feature (such as keyagreement@domain or service@domain).

Any numeric code in a private range SHOULD be administrated by the 
entity that owns the @domain of the previously negotiated protocol 
feature. The specification of the domain specific feature MIGHT add 
further restrictions and implementations SHOULD respect these 
restrictions to avoid interoperability problems.

Also note that the phrase...

>> implementations, but will never conflict with a standard 

...is illogical. If the standard states that an implementation MIGHT use 
numbers in the private range, and the implementation does use numbers in 
the private range, then the implementation *is* standard compliant. (I 
hope this point is made clear by the paragraphs I wrote above.)

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 26 Sep 2004 21:01:45 -0700 (PDT)

Hi,

> >> implementations, but will never conflict with a standard

Are there any objections to this allocation scheme?  If not, I'll use it
for the Disconnection Code 'reason code's and as the model for other
uint32 ranges.

> > don't establish separate registries for the method-specific message

A reservation of the range is appropriate but it won't be a registry.
If the range 0xFE000000..0xFEFFFFFF is not for IETF registered codes then
it won't be appropriate to ask the IANA to maintain a registry.

Let me propose an example just to make sure that we're all on the same
page with this.

Let's say that some router company comes up with a great channel-type for
thingees between routers, which we'll call "[email-masked]".
We can also say that it will use all of the IETF-defined Disconnection
Code 'reason code's plus an additional one locally defined as 0xFE000000.

Let's also say that a wonderful channel-type is defined specifically for
linux devices by some linux producer, which we'll call
"[email-masked]".  We can also say that it will use all of the
IETF-defined Disconnection Code 'reason code's plus one additional one
locally defined as 0xFE000000.  Which is the same 'reason code' as that
defined by routerco.com.

While these are maintained at the whims of their respective organizations,
others may choose to utilize them; other manufacturors of routers may also
use the channel defined as "[email-masked]", and other linux
producers may also decide to use "[email-masked]".

> restrictions to avoid interoperability problems.

If Otherrouter, Inc. (owner of the domain otherrouter.com) uses the
channel of ""[email-masked]" but they want to additionally
define another Disconnection Code 'reason code', then they have 3 ways to
try to do it:
 - get routerco.com to add it in (they would have to support it as well)
 - define a new channel-type as "[email-masked]" with the
   new 'reason code'
 - produce an RFC that will define the new channel (superseding
   "greatchannel@*.com") along with all of the Disconnection Code 'reason
   code's.

> hope this point is made clear by the paragraphs I wrote above.)

If all of the above is as everyone expects, then I'll work in the
appropriate language.

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 27 Sep 2004 13:45:59 +0200

Chris Lonvick <[email-masked]> writes:

> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,

> for the Disconnection Code 'reason code's and as the model for other

Note that the above scheme is applicable only to the reason codes in
SSH_MSG_CHANNEL_OPEN_FAILURE.

The reason codes for SSH_MSG_DISCONNECT can not be associated with any
channel type. After all, the transport protocol can be used with
"services" very different from "ssh-connection", and the definition of
the transport protocol should not refer to concepts in the connection
protocol.

(Personally, I don't understand what all the currently defined
SSH_DISCONNECT_* codes are supposed to be useful for. And I find it
fairly unlikely that private use codes at that level will be very
useful either. It's nice to people experimenting with the protocol to
have a local use space, and I fully support reserving 0xff000000 -
0xffffffff for private use, but I don't expect that space to actually
be used very often).

Regards,
/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Sep 2004 10:57:49 -0400

> SSH_MSG_CHANNEL_OPEN_FAILURE.

Right; the channel-type-specific range makes sense only for messages which 
occur in the context of a particular channel.  Global mesasges like 
SSH_MSG_DISCONNECT cannot be associated with any particular channel, and 
should not define this range.

Note that there is no reason to restrict the use of the 0xFE range to 
privately-defined channel types.  It is IMHO entirely reasonable for a 
standards-track channel type to defined a channel-type-specifc code.  Such 
a code would be specified in the document defining the channel type and 
would be drawn from the 0xFE range, without regard to use of codes in that 
range by other channel types.