Note that this is not a general defence against compromised clients
(that is impossible), but it thwarts a simple attack.
-5. sftp: Reversal of arguments to SSH_FXP_SYMLINK
+5. connection: Tunnel forward extension "tun@openssh.com"
+
+OpenSSH supports layer 2 and layer 3 tunneling via the "tun@openssh.com"
+channel type. This channel type supports forwarding of network packets
+with datagram boundaries entact between endpoints equipped with
+interfaces like the BSD tun(4) device. Tunnel forwarding channels are
+requested by the client with the following packet:
+
+ byte SSH_MSG_CHANNEL_OPEN
+ string "tun@openssh.com"
+ uint32 sender channel
+ uint32 initial window size
+ uint32 maximum packet size
+ uint32 tunnel mode
+ uint32 remote unit number
+
+The "tunnel mode" parameter specifies whether the tunnel should forward
+layer 2 frames or layer 3 packets. It may take one of the following values:
+
+ SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */
+ SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
+
+The "tunnel unit number" specifies the remote interface number, or may
+be zero to allow the server to automatically chose an interface. A server
+that is not willing to open a client-specified unit should refuse the
+request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open,
+the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
+
+Once established the client and server may exchange packet or frames
+over the tunnel channel by encapsulating them in SSH protocol strings
+and sending them as channel data. This ensures that packet boundaries
+are kept intact. Specifically, packets are transmitted using normal
+SSH_MSG_CHANNEL_DATA packets:
+
+ byte SSH_MSG_CHANNEL_DATA
+ uint32 recipient channel
+ string data
+
+The contents of the "data" field for layer 3 packets is:
+
+ uint32 packet length
+ uint32 address family
+ byte[packet length - 4] packet data
+
+The "address family" field identifies the type of packet in the message.
+It may be one of:
+
+ SSH_TUN_AF_INET 2 /* IPv4 */
+ SSH_TUN_AF_INET6 24 /* IPv6 */
+
+The "packet data" field consists of the IPv4/IPv6 datagram itself
+without any link layer header.
+
+The contents of the "data" field for layer 3 packets is:
+
+ uint32 packet length
+ byte[packet length] frame
+
+The "frame" field contains an IEEE 802.3 ethernet frame, including
+header.
+
+6. sftp: Reversal of arguments to SSH_FXP_SYMLINK
When OpenSSH's sftp-server was implemented, the order of the arguments
to the SSH_FXP_SYMLINK method was inadvertendly reversed. Unfortunately,
string targetpath
string linkpath
-6. sftp: Server extension announcement in SSH_FXP_VERSION
+7. sftp: Server extension announcement in SSH_FXP_VERSION
OpenSSH's sftp-server lists the extensions it supports using the
standard extension announcement mechanism in the SSH_FXP_VERSION server
extension with multiple versions (though this is unlikely). Clients MUST
check the version number before attemping to use the extension.
-7. sftp: Extension request "posix-rename@openssh.com"
+8. sftp: Extension request "posix-rename@openssh.com"
This operation provides a rename operation with POSIX semantics, which
are different to those provided by the standard SSH_FXP_RENAME in
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
-8. sftp: Extension requests "statvfs@openssh.com" and
+9. sftp: Extension requests "statvfs@openssh.com" and
"fstatvfs@openssh.com"
These requests correspond to the statvfs and fstatvfs POSIX system
This extension is advertised in the SSH_FXP_VERSION hello with version
"2".
-$OpenBSD: PROTOCOL,v 1.6 2008/06/10 22:15:23 djm Exp $
-
+$OpenBSD: PROTOCOL,v 1.7 2008/06/12 05:15:41 djm Exp $