headers
Chris Lonvick | 13 Sep 2004 17:40
Picon
Favicon

Re: query about draft-ietf-secsh-connect-19.txt

Hi,

Refreshing this discussion:

On Fri, 13 Aug 2004 14:09:51 +0100
Anil Madhavapeddy <anil <at> recoil.org> wrote:

In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference
to:

byte     SSH_MSG_GLOBAL_REQUEST_SUCCESS
uint32   port that was bound on the server

which should probably be "SSH_MSG_REQUEST_SUCCESS"

The other odd thing about this packet is that it's the only one which
doesn't encode the request type in which it's in response to.

This form would appear to make more sense:

byte    SSH_MSG_REQUEST_SUCCESS
string  "tcpip-forward"
uint32  port that was bound on the server

As this is the only packet for which the contents of the packet can
vary without a "constant field" on which to make the decision of which
further packets to inspect.  In other cases, e.g. SSH_MSG_CHANNEL_REQUEST,
the decision to decode further fields can be taken by lookinng at the
first string argument.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Autoreply | 16 Sep 2004 18:06
Picon

Re: Mail Delivery (failure thomas.gruhlke <at> spk-sal.de)


Sehr geehrte Kundin, sehr geehrter Kunde,

vielen Dank für Ihre soeben eingegangene E-Mail. Sollte Ihre E-Mail einen
legitimationspflichtigen Auftrag (z. B. Überweisung, Wertpapierauftrag,
etc.) enthalten, bitten wir Sie um Verständnis, dass wir zu Ihrer eigenen
Sicherheit diesen Auftrag nicht ausführen können, da eine
Fälschungssicherheit bei E-Mails nicht gewährleistet werden kann.

Für eine Vielzahl von unterschriftspflichtigen Aufträgen können wir Ihnen
entsprechend gesicherte Alternativen anbieten. Wir beraten Sie gerne.

Mit freundlichen Grüßen

Ihre Sparkasse Stade-Altes Land
Permalink | Reply | 0 comments |
headers
denis bider | 18 Sep 2004 22:26

RE: query about draft-ietf-secsh-connect-19.txt

> It appears that some changes need to be made to [connect].
...
> 2) Make a decision that [connect] must either
>   a) mandate that replies to channel requests MUST be in order, or
>   b) change the protocol to have the responses identify the channel.
> I'm betting that this group will opt for (a).  If so, could 
> someone please propose some text.

Beg pardon?

Responses do identify the channel.

>      byte      SSH_MSG_CHANNEL_SUCCESS
>      uint32    recipient_channel
> --
>      byte      SSH_MSG_CHANNEL_FAILURE
>      uint32    recipient_channel

[CONNECT] should mandate that replies to channel requests need not be in order
overall, but must be in order for each channel. Replies to global requests must
be in order overall.
Permalink | Reply | 5 comments |
headers
Chris Lonvick | 20 Sep 2004 16:57
Picon
Favicon

RE: query about draft-ietf-secsh-connect-19.txt

Hi,

On Sat, 18 Sep 2004, denis bider wrote:

> > It appears that some changes need to be made to [connect].
> ...
> > 2) Make a decision that [connect] must either
> >   a) mandate that replies to channel requests MUST be in order, or
> >   b) change the protocol to have the responses identify the channel.
> > I'm betting that this group will opt for (a).  If so, could
> > someone please propose some text.
>
>
> Beg pardon?
>
> Responses do identify the channel.
>
>
> >      byte      SSH_MSG_CHANNEL_SUCCESS
> >      uint32    recipient_channel
> > --
> >      byte      SSH_MSG_CHANNEL_FAILURE
> >      uint32    recipient_channel
>
>
> [CONNECT] should mandate that replies to channel requests need not be in order
> overall, but must be in order for each channel. Replies to global requests must
> be in order overall.

OK.  I've added text to the bottom of Section 4 "Global Requests" as
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joseph Galbraith | 20 Sep 2004 17:40
Favicon

Re: query about draft-ietf-secsh-connect-19.txt

Chris Lonvick wrote:
> Hi,
> 
> On Sat, 18 Sep 2004, denis bider wrote:
> 
> 
>>>It appears that some changes need to be made to [connect].
>>
>>...
>>
>>>2) Make a decision that [connect] must either
>>>  a) mandate that replies to channel requests MUST be in order, or
>>>  b) change the protocol to have the responses identify the channel.
>>>I'm betting that this group will opt for (a).  If so, could
>>>someone please propose some text.
>>
>>
>>Beg pardon?
>>
>>Responses do identify the channel.
>>
>>
>>
>>>     byte      SSH_MSG_CHANNEL_SUCCESS
>>>     uint32    recipient_channel
>>>--
>>>     byte      SSH_MSG_CHANNEL_FAILURE
>>>     uint32    recipient_channel
>>
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Niels Möller | 20 Sep 2004 20:47
Picon
Picon
Picon
Favicon

Re: query about draft-ietf-secsh-connect-19.txt

Chris Lonvick <clonvick <at> cisco.com> writes:

> OK.  I've added text to the bottom of Section 4 "Global Requests" as
> follows:
> 
>    In general, the reply messages do not include request type
>    identifiers.  To make it possible for the originator of a request to
>    identify to which request each reply refers, it is REQUIRED that
>    replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
>    the corresponding request messages.  For channel requests, replies
>    that relate to the same channel MUST also be replied to in the right
>    order.  However, channel requests for distinct channels MAY be
>    replied to out-of-order.
> 
> 
> Is this acceptable?

It's ok. I think it could be improved slightly by striking the first
sentence.

(The request type is mostly irrelevant when it comes to disambiguating
replies, as one may well have several outstanding requests of the same
type; I think mentioning it as a possible alternative will just add
more confusion).

Regards,
/Niels
Permalink | Reply | 0 comments |
headers
Anil Madhavapeddy | 20 Sep 2004 21:02
Gravatar

Re: query about draft-ietf-secsh-connect-19.txt

On Mon, Sep 20, 2004 at 07:57:34AM -0700, Chris Lonvick wrote:
> 
>    In general, the reply messages do not include request type
>    identifiers.  To make it possible for the originator of a request to
>    identify to which request each reply refers, it is REQUIRED that
>    replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
>    the corresponding request messages.  For channel requests, replies
>    that relate to the same channel MUST also be replied to in the right
>    order.  However, channel requests for distinct channels MAY be
>    replied to out-of-order.

Looks fine to me.

--

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk
Permalink | Reply | 0 comments |
headers
denis bider | 20 Sep 2004 20:59

RE: query about draft-ietf-secsh-connect-19.txt

> > OK.  I've added text to the bottom of Section 4 "Global Requests" as
> > follows:
> > 
> >    In general, the reply messages do not include request type
> >    identifiers.  To make it possible for the originator of 
> a request to
> >    identify to which request each reply refers, it is REQUIRED that
> >    replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the 
> same order as
> >    the corresponding request messages.  For channel 
> requests, replies
> >    that relate to the same channel MUST also be replied to 
> in the right
> >    order.  However, channel requests for distinct channels MAY be
> >    replied to out-of-order.
> > 
> > 
> > Is this acceptable?
> 
> This sounds good to me.

Sounds good to me too.
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 24 Sep 2004 05:16
Picon
Favicon

Message Numbers and Disconnect Codes

Hi Folks,

I need to bring this up again.  :)  In the last go-around, I made the
mistake of saying that the Disconnection Codes 'reason code' value was a
byte.  The document clearly states, however, that it is a uint32.  My bad.
Since we agreed that the high 16 values (what we said were going to be
239..254) would be reserved for local use, I'd like to suggest that this
be retained.  This would mean that the values of 0x00000001..0xFFFFFFE9
will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will
be reserved for local use.

I've also found a couple of more items that need to be listed in
[NUMBERS].  Including the Disconnection Codes we have:

Disconnection Codes                  from Section 11 in [TRANS]
      byte      SSH_MSG_DISCONNECT
      uint32    reason code
      string    description [RFC3629]
      string    language tag [RFC3066]
'reason code' values of 1..15 are assigned

Channel Connection Failure           from Section 5.1 in [CONNECT]
      byte      SSH_MSG_CHANNEL_OPEN_FAILURE
      uint32    recipient channel
      uint32    reason code
      string    additional text
      string    language tag
'reason code' values of 1..4 are assigned

Extended Channel Data Transfer       from Section 5.2 in [CONNECT]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joseph Galbraith | 24 Sep 2004 06:01
Favicon

Re: Message Numbers and Disconnect Codes

Chris Lonvick wrote:
> Hi Folks,
> 
> I need to bring this up again.  :)  In the last go-around, I made the
> mistake of saying that the Disconnection Codes 'reason code' value was a
> byte.  The document clearly states, however, that it is a uint32.  My bad.
> Since we agreed that the high 16 values (what we said were going to be
> 239..254) would be reserved for local use, I'd like to suggest that this
> be retained.  This would mean that the values of 0x00000001..0xFFFFFFE9
> will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will
> be reserved for local use.
> 
> I've also found a couple of more items that need to be listed in
> [NUMBERS].  Including the Disconnection Codes we have:
> 
> 
> Disconnection Codes                  from Section 11 in [TRANS]
>       byte      SSH_MSG_DISCONNECT
>       uint32    reason code
>       string    description [RFC3629]
>       string    language tag [RFC3066]
> 'reason code' values of 1..15 are assigned
> 
> 
> Channel Connection Failure           from Section 5.1 in [CONNECT]
>       byte      SSH_MSG_CHANNEL_OPEN_FAILURE
>       uint32    recipient channel
>       uint32    reason code
>       string    additional text
>       string    language tag
(Continue reading)

Permalink | Reply | 0 comments |

Gmane