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

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Jeffrey Hutzelman wrote:
> 
> 
> On Wednesday, March 07, 2007 08:34:36 AM -0700 Joseph Galbraith
> <galb-list%vandyke.com@localhost> wrote:
> 
>> 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?
> 
> 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.

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

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