Subject: Re: draft-bjh21-ssh-transport-extension-01

From: Joseph Galbraith <[email-masked]>
Date: Wed, 07 Mar 2007 08:34:36 -0700

Ben Harris wrote:
> 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>

I just read this through with an eye towards implementing it,
and have several comments:

1. Did I just miss it, or is the message number actually not yet
   defined?

2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
   reasonably possible to identify which packet was unimplemented.)

   For unrecognized extensions, I'd rather see a predefined
   extension:

   byte      SSH_MSG_TRANSPORT_EXTENSION
   string    "unrecognized-extension"

   that should be sent in response to a extension the implementation
   doesn't recognize.

   This has the advantage that the sender can differentiate between
   implementations not implementing the draft and implementations
   not implementing the extension.

3. Do we need a nod to in-order vs. out-of-order processing:

   Much of the SSH protocol allows multiple requests to be
   made before receiving a response.  For any given extension
   requiring a response, the extension MUST define whether
   multiple outstanding requests are to be allowed, and if so,
   whether there are constraints on the ordering of the
   processing and responses.

Thanks,

Joseph

---

From: Simon Tatham <[email-masked]>
Date: Wed, 07 Mar 2007 15:48:49 +0000

>    reasonably possible to identify which packet was unimplemented.)

Why not? You can remember the sequence number when you construct
your outgoing packets.

I admit I have no first-hand experience of actually trying this, but
I'd imagine that there aren't _many_ circumstances under which you
can recover from SSH_MSG_UNIMPLEMENTED and continue a useful
session. In other words, you'd be able to identify _specific_
outgoing packets on your side of the connection for which you'd be
interested in noticing SSH_MSG_UNIMPLEMENTED. Then you can remember
the sequence number of each of those specific packets until you
receive either the SSH_MSG_UNIMPLEMENTED or the expected response.
For any packet for which you _don't_ have a defined
SSH_MSG_UNIMPLEMENTED handler, there's nothing you can really do
except to terminate the session on the grounds that the other side
refused to deal with something you couldn't manage without.
-- 
Simon Tatham         "My heart bleeds.
<[email-masked]>    (That's how it works.)"   -- Gareth Taylor

---

From: der Mouse <[email-masked]>
Date: Wed, 7 Mar 2007 11:09:40 -0500 (EST)

>    reasonably possible to identify which packet was unimplemented.)

This is no worse than the stock protocol with respect to channel
requests.

> [...]
>    implementations not implementing the draft and implementations not
>    implementing the extension.

Why would a sender care?  I'm having trouble thinking of a reason.

/~\ 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: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Mar 2007 11:03:14 -0500

> 1. Did I just miss it, or is the message number actually not yet

No, you didn't miss it.  The actual message number won't be assigned by 
IANA until after the spec has been approved by the IESG.  This is normal 
for assignments requiring IESG approval and/or IETF consensus action.

>    not implementing the extension.

I'm not sure whether this is necessary, but if it is, then it's likely also 
necessary to indicate _which_ extension was unexported.

> 3. Do we need a nod to in-order vs. out-of-order processing:

Yes, that's probably a good idea.

-- Jeff

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 07 Mar 2007 09:29:11 -0700

> Why would a sender care?  I'm having trouble thinking of a reason.

Well, the use case that comes to my mind is that if the draft
isn't implemented, the sender might which to avoid sending any
further extensions, but if it is just a specific extension,
the sender might care to use other extensions.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 07 Mar 2007 09:17:42 -0700

> for assignments requiring IESG approval and/or IETF consensus action.

Ahh... I suspected something like that, but wanted to make
sure.

> I'm not sure whether this is necessary, but if it is, then it's likely
> also necessary to indicate _which_ extension was unexported.

Yes, I was just realizing that my proposal was insufficient for
what I wanted.

  byte      SSH_MSG_TRANSPORT_EXTENSION
  string    "unrecognized-extension"
  string    the-unrecognized-extension

I do realize that it is possible to track the sequence
numbers of suspect outgoing packets (as suggested by
Simon in a separate email) but I wasn't considering
that an reasonable mechanism, for a couple of reasons:

A. We can do better-- rather than forcing tracking,
   we can simply tell the requester what extension
   was not recognized.
B. Forcing tracking might preclude some uses for
   the extension, where either numerous packets
   need to be sent or the time-to-live of a request
   is not well defined, or is extra-ordinarily long.

   I'm sure that these problems could be worked around...
   but why not just avoid the problem?

Thanks,

Joseph

---

From: Ben Harris <[email-masked]>
Date: Wed, 7 Mar 2007 16:28:15 +0000 (GMT)

> 3. Do we need a nod to in-order vs. out-of-order processing:

I don't think so, for the same reason that I dropped the security 
consideration about packets sent before SSH_MSG_NEWKEYS: the issue applies 
to all extensions that define new message types, whether they do it by 
assigning a whole message number or by using a named message.  It would be 
perverse to impose a more stringent requirement on named messages than on 
numbered ones.

On your other points, Simon's and der Mouse's replies cover everything I 
was going to say.

-- 
Ben Harris