Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt

From: Jeffrey Altman <[email-masked]>
Date: Sat, 16 Dec 2000 12:39:47 EST

> 
> That's not at all how I'm thinking. My scenario is as follows: I
> choose a private use message number, say 217, for some special message
> in the communication between lsh and lshg (the programs communicate by
> means of the unencrypted transport protocol, over a local unix
> socket).
> 
> Next, some site using lsh or some other secsh implementation chooses a
> private use number for somthing else, and also happen to choose 217 =>
> trouble when they use lshg.
> 
> It seems that using distinct classes for the two types of extensions
> (those added by an implementation, and those of local configuration or
> hacks) may be a good idea.

This is properly handled not by setting allocating a special range for
local hacks, but by you instructing anyone hacking your code not to
use certain values.    From the perspective of the rest of the
implementations there is no difference between a local hack and a
private extension to lsh.  If there is a clash in the private use name
space the behavior is undefined.  

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: [email-masked] (Niels M�ller)
Date: 18 Dec 2000 21:58:59 +0100

Jeffrey Altman <[email-masked]> writes:

> use certain values.

Thanks, that's good advice.

> From the perspective of the rest of the implementations there is no
> difference between a local hack and a private extension to lsh. If
> there is a clash in the private use name space the behavior is
> undefined.

Not necessarily. I'll try to explain, even if it may be a little
obscure. Consider the following setup:

  local hack A <-> lsh <-> network <-> locally A-hacked secsh server
            lshg L-^

Here, the A-hack and lshg are communicating, using a single lsh and an
lsh gateway to setup the connection at one end of the network. They
don't need to know about each other, and lsh doesn't need to know the
hacks. The gateway just passes unknown messages on without any
processing. However, if lsh and lshg also have some internal
communication using "private use" message numbers, they can collide
with the hack.

Ok, I don't even know yet if lsh and lshg will use any new message
numbers, and one can always add an extra layer of encapsulation in the
gateway protocol, but if the problem could be solved by subdividing
the private use area, that would be convenient.

I guess I should drop this now, but I hope you at least understand the
scenario?

/Niels