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

From: Ben Harris <[email-masked]>
Date: Sat, 17 Feb 2007 21:42:54 +0000 (GMT)

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 [email-masked].  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>

-- 
Ben Harris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 17 Feb 2007 21:00:24 -0500

> <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension-

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

---

From: der Mouse <[email-masked]>
Date: Mon, 19 Feb 2007 03:30:36 -0500 (EST)

> [...] a race-free version of [email-masked].

Speaking of which, can anyone point me to docs on the various
@openssh.com names?  Besides [email-masked] as a compression method,
I've seen [email-masked] channel requests, and have so far been
unable to find authoritative documentation on either.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Mon, 19 Feb 2007 04:30:55 -0500 (EST)

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

Named *transport-layer* message types, it seems to me.  Or am I
misreading?

> What do people think of this idea?

"Good."  I don't have any immediate use for it (the one new packet type
I'm using more appropriately falls into the "local extension" range
192-255, since it never appears on the wire), but I agree that it's a
very good thing to have.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Ben Harris <[email-masked]>
Date: Wed, 21 Feb 2007 23:26:22 +0000

>performance implications which make it a good idea to consume a number.

I've added something like that to the end of the introduction.

>would apply equally to messages using new numbers.

This is true and I've dropped that paragraph.  It really belongs in a 
"security considerations for extending SSH" document which doesn't exist 
yet.

I'll upload -01 tonight.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Sat, 24 Feb 2007 16:29:30 +0000

I've uploaded a new version of my transport extension draft which I 
think addresses everyone's comments.  Any more before I wave it at the 
IESG?  In particular, I'm wondering if I should extend it to allocate 
similar message numbers for extensions to ssh-userauth and/or 
ssh-connect.

<http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension-01.txt>

-- 
Ben Harris

---

From: Joseph Galbraith <[email-masked]>
Date: Sat, 24 Feb 2007 19:22:46 -0700

> <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension-01.txt>

Userauth might be a good idea; ssh-connect already has
SSH_MSG_GLOBAL_REQUEST, which serves this purpose.

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Feb 2007 13:41:06 -0500

> SSH_MSG_GLOBAL_REQUEST, which serves this purpose.

Userauth really shouldn't need this.  There is a space of 20 message 
numbers whose meanings are defined on a per-method basis, and new 
non-method-specific userauth messages should be extremely rare.

OTOH, the rarity argument can also be made for transport messages, and the 
scarity-of-numbers argument applies at least as well to userauth, so I 
suppose I won't object if you want to do it.

-- Jeff

---

From: Ben Harris <[email-masked]>
Date: Tue, 27 Feb 2007 23:03:31 +0000 (GMT)

On Mon, 26 Feb 2007, Jeffrey Hutzelman wrote:

> > Ben Harris wrote:
> > > In particular, I'm wondering if I should extend it to allocate
> Userauth really shouldn't need this.  There is a space of 20 message numbers
> whose meanings are defined on a per-method basis, and new non-method-specific
> userauth messages should be extremely rare.
> 
> scarity-of-numbers argument applies at least as well to userauth,

I think I disagree slightly with that.  Userauth has 16 unallocated 
message numbers where transport has 13, and I've got two extensions in 
mind that would need transport message types, but none that would need 
userauth ones.  I think for the moment, I'm minded to leave userauth (and 
connect) out.

-- 
Ben Harris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Feb 2007 21:21:07 -0500 (EST)

> userauth ones.  I think for the moment, I'm minded to leave userauth (and

Userauth has 6 unallocated generic numbeers, not 16.
Anyway, as I said, I don't much care one way or the other.

-- Jeff