Subject: tcpip-forward requests and bind addresses

From: Darren Tucker <[email-masked]>
Date: Sat, 29 Jan 2005 03:58:37 +1100

Hi all.

Section 7.1 in draft-ietf-secsh-connect-23.txt is unclear on several 
aspects of specifying bind addresses in port forwarding requests.  It says:

[quote]
             byte      SSH_MSG_GLOBAL_REQUEST
             string    "tcpip-forward"
             boolean   want reply
             string    address to bind (e.g., "0.0.0.0")
             uint32    port number to bind

    The 'address to bind' and 'port number to bind' specify the IP
    address and port to which the socket to be listened is bound.  The
    address should be "0.0.0.0" if connections are allowed from anywhere.
    (Note that the client can still filter connections based on
    information passed in the open request.)
[/quote]

The things that aren't clear:
  - how to listen on all IPv4 and IPv6 interfaces.
  - how to listen on localhost only on IPv4 and IPv6

Working with Damien Miller, we've come up with the following 
suggestions.  After some digging, it turns out we're (belatedly) 
seconding suggestions made by Niels Möller[1] in 2001!

(1) the string "" should specify that connections are allowed from anywhere

rationale: since we're not specifying an address, logically it could 
mean "any address is acceptable" or "no address is acceptable".  The 
latter case is handled by not sending a tcpip-forward at all, so the 
former should be the obvious meaning.

(2) "address to bind" should permit either a domain name or address

rationale: direct-tcpip permits this, and the server may have better 
information about its addresses (eg "servername-hme0" to listen on that 
interface on both IPv4 and IPv4).  The client still has the option of 
doing a lookup locally and/or sending an address instead.

(3) the string "localhost" should have a special meaning to the server 
of "all loopback IPv4 and IPv6 interfaces".

rationale: a properly configured host should get this anyway from its 
name resolver.  Making it a special case removes a dependancy on the 
name service that could potentially be used to compromise forwarded 
connections.

An older client talking to a newer server will still be fully compatible 
with these; a newer client talking to an older server potentially may 
not, however this may be trivally overcome by configuration, eg manually 
specifying "0.0.0.0" as a listen address instead of (1).

With those in mind, I'd like to suggest the following text to replace 
the first paragraph in section 7.1:

[proposed text]
The 'address to bind' and 'port number to bind' specify the IP address 
or domain name and port to which the socket to be listened is bound. The 
address should be "" if connections are to accepted from anywhere on all 
supported protocol families.

The server SHOULD treat an address of "localhost" to be a special case 
meaning to listen on all supported protocol families on its loopback 
interfaces only.

The strings "0.0.0.0" and "::" should be used to listen on all 
interfaces on only IPv4 or IPv6 respectively.  Similarly, strings of 
"127.0.0.1" or "::1" should be used to listen on the loopback interface.

Note that the client can still filter connections based on information 
passed in the open request.
[/proposed text]

     Thanks and regards,
         -Darren Tucker.

[1] http://article.gmane.org/gmane.ietf.secsh/2299

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.