IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: draft-bjh21-ssh-transport-extension-00




On Saturday, February 17, 2007 09:42:54 PM +0000 Ben Harris <bjh21%bjh21.me.uk@localhost> wrote:
I've just uploaded an internet-draft that would allocate an SSH message
number to be used for named message types, where the names work like all
the other names in SSH.  This should make it easier to extend the SSH
transport layer in ways that need new message types, as it appears might
be necessary to produce a race-free version of zlib%openssh.com@localhost.  Named
packet types aren't right for everything, of course, but they seem
sensible for packets that are only likely to be sent a few times per
connection.

What do people think of this idea?

<http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension-
00.txt>
Sounds like a good idea.  I can't find evidence of any reason to restrict 
allocation of transport-level message numbers other than the extreme 
scarcity of the namespace, so opening it up in the way you describe seems 
reasonable.
I think it is probably worth noting that anyone defining a standards-track 
extension requiring a new transport-level message would now have a choice 
as to whether to allocate a new message type number or used a named type. 
This decision would presumably be made on the basis of whether there are 
performance implications which make it a good idea to consume a number.
I think the advice you give in the security considrations section is 
misplaced.  The question of whether to send a message prior to completion 
of the initial key exchange depends on the semantics of the message in 
question and whether it can live with the lack of integrity protection. 
While it's pretty likely that the number of such messages is small and they 
have all already been defined, there is no guarantee of that.  In any 
event, the question is unrelated to the use of named message types; it 
would apply equally to messages using new numbers.
At a minimum, this text should be reworded as advice to designers as future 
extensions, without use of RFC2119 keywords which appear to specify 
behavior for implementations.


-- Jeff



Home | Main Index | Thread Index | Old Index