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

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 15 Dec 2000 13:39:16 -0500

ok, i withdraw the proposal for the third intermediate class.

suggested text:

 - protocol names are divided into two classes:
   - names with @ signs in them are allocated by the owner of the DNS
name after the @ sign ("hierarchical allocation" in 2434 terms)
  - @-free names should be allocated by IETF consensus.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 18 Dec 2000 17:47:46 EST

> 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?
> 

I'm not sure that subdividing the address space will solve this
problem.  What it sounds like is that you need two different kinds of
messages numbers.  One type that gets forwarded when not recognized,
and the other that does not.  But again I think this is tied to your
implementation of lsh[g].

 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.