RFC Errata
Found 2 records.
Status: Verified (2)
RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006
Note: This RFC has been updated by RFC 8308
Source of RFC: secsh (sec)
Errata ID: 6850
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hamid Nazari
Date Reported: 2022-02-14
Verifier Name: Paul Wouters
Date Verified: 2023-07-28
Section 5.1 says:
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' values (and associated 'description' text) in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
It should say:
Requests for assignments of new SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values (and associated 'description' text) in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
Notes:
The 'reason code' is present on SSH_MSG_CHANNEL_OPEN_FAILURE message to denote cause of the failure while original text attributes it to SSH_MSG_CHANNEL_OPEN by mistake.
Errata ID: 3878
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2014-02-02
Verifier Name: Stephen Farrell
Date Verified: 2015-05-12
Section 5.2 says:
The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty.
It should say:
The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the length of the data sent, length field included. Both parties MAY ignore all extra data sent after the allowed window is empty.
Notes:
This is the data transfer packet:
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.
It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.