Subject: Re: tcpip-forward requests and bind addresses

From: [email-masked] (Niels Möller)
Date: 14 Feb 2005 16:05:50 +0100

Darren Tucker <[email-masked]> writes:

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

It seems I haven't changed my mind since back then ;-). I like your
proposed text, with only one minor concern (see below).

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

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

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

> [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]

I have some concern with the phrase "all supported protocol families".
I don't think it is wise to interpret that as "all protocol families
that getaddrinfo return". It should be IPv4, IPv6 and, beyond that,
only protocol families that *really* make sense to implementor and/or
local sysadm.

One simple argument against random protocol families is that we don't
specify what the "originator IP address" and "originator port" in
SSH_MSG_CHANNEL_OPEN "forwarded-tcpip".

Regards,
/Niels

---

From: der Mouse <[email-masked]>
Date: Mon, 14 Feb 2005 11:44:49 -0500 (EST)

>> [connection forwarding stuff]
> I have some concern with the phrase "all supported protocol
> families".  I don't think it is wise to interpret that as "all
> protocol families that getaddrinfo return".  It should be IPv4, IPv6
> and, beyond that, only protocol families that *really* make sense to
> implementor and/or local sysadm.

Consider, for example, a dual-stack IP-and-DECnet machine.

> SSH_MSG_CHANNEL_OPEN "forwarded-tcpip".

This sentence is incomplete; there appears to be a verb missing.

This too has always struck me as a problem with ssh: it is rather
thoroughly IP-centric, whereas there is no inherent reason it couldn't
be designed so as to be usable over any reliable octet stream (DECnet
is my usual gedanken example).

For example, consider agent forwarding and port forwarding; both are
specified in a way which is impossible to extend to, say, DECnet, since
they do not have any kind of protocol identifier.  You'd have to design
a parallel set of requests to do the analogous things with some other
protocol.  (Putting "tcpip" in the names of the port-forwarding
messages helps make this obvious for that one, but the
forwarding-notice message really needs a redesign.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Feb 2005 13:38:08 -0500

> is my usual gedanken example).

There is only one Internet Protocol.
This design philosophy is a fundamental part of the internet architecture.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: der Mouse <[email-masked]>
Date: Mon, 14 Feb 2005 13:49:39 -0500 (EST)

>> thoroughly IP-centric, [...]

Must be nice to be able to live in such a blinkered environment.  I use
two different ones fairly commonly even today (IPv4 and IPv6), and once
upon a time used another (DECnet) not uncommonly, though it's been some
years since I had much to do with it.

I suppose you will try to finesse this by defining "Internet Protocol"
suitably.  Go ahead; it doesn't bother me what kind of blinkers you
want to wear - I'm not interested in wearing them.

> This design philosophy is a fundamental part of the internet

Tell that to X11, which supported non-IP connections (FamilyDECnet,
FamilyChaos) before IPv6 even existed.

I see no reason why every - or indeed any - protocol design has to buy
into this "today's IP is the One True Way" philosophy.

Fortunately ssh is designed well enough that it won't be that
difficult.  Port forwarding just needs a parallel set of messages
designed to replace the *tcpip* ones.  Agent forwarding needs to grab a
message number to replace FORWARDING_NOTICE.  Nothing too demanding.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 14 Feb 2005 18:08:13 -0500

> only protocol families that *really* make sense to implementor and/or

Agreed.

> SSH_MSG_CHANNEL_OPEN "forwarded-tcpip".

There exist protocols which use the IP addressing model but not ip wire 
encoding.  These protocols tend to be problematic administratively but
they clearly *could* be included in a wildcard bind.

Given that you can use this option to tunnel between addressing universes
we're already stuck with essentially implementation-defined behavior 
from the receiver..

						- Bill

---

From: Darren Tucker <[email-masked]>
Date: Tue, 15 Feb 2005 10:26:41 +1100

> only protocol families that *really* make sense to implementor and/or

I meant "all protocol families supported by the SSH implementation" not 
"all protocol families supported by the platform".

For most current implementations that would probably be IPv4 or IPv4+IPv6 
but there could be others if the implementation supports them.

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

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 15 Feb 2005 07:03:21 -0800 (PST)

Hi,

Current text in [CONNECT]-23 Section 7.1:
   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.)

I took Darren's original proposal, merged in the responses and made an
attempt at reorganizing it.

[new proposed text]

   The address SHOULD be "" if connections are to accepted from anywhere
   on all protocol families supported by the SSH implementation.  The
   strings "0.0.0.0" and "::" SHOULD be used to listen on all interfaces
   on only IPv4 or IPv6 respectively.

   The server SHOULD treat an 'address to bind' of "localhost" to be a
   special case meaning to listen on all supported protocol families on
   its loopback interfaces only.  Similarly, the numerically assigned
   loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] SHOULD be
   used to listen on the loopback interface with only IPv4 or IPv6
   respectively.

[/new proposed text]

Please review this.  I've changed some "should"s to "SHOULD"s (should any
of these be left as "should"s or changed to "MUST"s?) and have added the
references of RFC3330 and RFC3515 to the loopback addresses.  I'd like to
get an okee-dokee on this rsn so I can submit the IDs before the cutoff
date.

Thanks,
Chris

---

From: der Mouse <[email-masked]>
Date: Tue, 15 Feb 2005 12:45:39 -0500 (EST)

> [new proposed text]
[edited down -dM]
>    on only IPv4 or IPv6 respectively.

I think SHOULD is the wrong word to use here.  What we are doing is
saying "as a special case, this string is defined to have this
semantic".  This is not a SHOULD any more than any of the other defined
semantics is.  The whole document is implicitly covered by an
"implementations SHOULD implement these esmantics", after all.

>    used to listen on the loopback interface with only IPv4 or IPv6

Here, the first SHOULD at least makes sense, though what it's really
doing is to define yet another special-case semantic.  The second one
here is in the same situation as the SHOULDs of the other paragraph
above.

I don't think the SHOULD/MUST/MAY language is appropriate here.  I'd
word this something like

    Some strings have special-case semantics: "" as an address to bind
    means that connections are to be accepted from anywhere on all
    protocol families supported by the SSH implementation.  "0.0.0.0"
    means to listen on all IPv4 addresses [note: not "interfaces"; the
    mapping between intefaces and addresses can be multi-valued in
    either direction].  "::" means to listen on all IPv6 addresses.
    "localhost" means to listen on all supported protocol families on
    loopback addresses only.  "127.0.0.1" and "::1", while not really
    special cases for a normally configured system [RFC3330] [RFC3515],
    indicate listening on the loopback interfaces for IPv4 and IPv6
    respectively.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Darren Tucker <[email-masked]>
Date: Wed, 16 Feb 2005 10:25:37 +1100

der Mouse wrote:
>>   its loopback interfaces only.
[...]
> doing is to define yet another special-case semantic.

The reason I said "SHOULD" is that some APIs have a guaranteed way of 
getting a loopback-only bind and I thought that would be preferable if 
available.  There may, however be a good reason for an implementation to 
rely on the name service for this, hence "SHOULD".

If the consensus is it's uncecessary it could be dropped and left as an 
implementation detail.

>     Some strings have special-case semantics: "" as an address to bind

"is an address" ?

>     means to listen on all IPv4 addresses

>     [note: not "interfaces"; the
>     either direction].

That's a good point.

>     "::" means to listen on all IPv6 addresses.
>     loopback addresses only.

"listen on all protocol families supported by the SSH implementation .." ?

>     "127.0.0.1" and "::1", while not really

Is RFC3515 a typo?

---

From: der Mouse <[email-masked]>
Date: Wed, 16 Feb 2005 00:04:51 -0500 (EST)

>>     Some strings have special-case semantics: "" as an address to bind

No.  Try reading it as
	"" as an address-to-bind parameter means that...

If you think the sense is OK but the wording can be improved, fine; I'm
not wedded to the wording, and the clearest wording we can find will be
none too clear for some of the people this needs to reach.

>>     "localhost" means to listen on all supported protocol families
>>     on loopback addresses only.

If you prefer; that's what "supported protocol families" really means
here anyway, and if anyone sees increased value in the wordier version,
I'm not going to kick about it.

>>     "127.0.0.1" and "::1", while not really special cases for a
>>     normally configured system [RFC3330] [RFC3515],
> Is RFC3515 a typo?

Looks like it, but not on my part.  The text I was basing that on was

   loopback strings of "127.0.0.1" [RFC3330] or "::1" [RFC3515] ...

which I (then) didn't bother sanity-checking.  I have now checked; 3515
is clearly not the right RFC, and I don't know offhand what is.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: [email-masked] (Niels Möller)
Date: 16 Feb 2005 08:51:07 +0100

> is clearly not the right RFC, and I don't know offhand what is.

I think it should be RFC 3513, "Internet Protocol Version 6 (IPv6)
Addressing Architecture".

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Feb 2005 04:25:12 -0800 (PST)

Hi,

> Addressing Architecture".

Yup.  My bad; fat fingers.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Feb 2005 05:51:02 -0800 (PST)

Hi,

How about the following which separates the thoughts into a list.

---

   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.
   Some strings used for the 'address to bind' have special-case
   semantics.

       "" means that connections are to be accepted from anywhere on all
       protocol families supported by the SSH implementation.

       "0.0.0.0" means to listen on all IPv4 addresses.  Note: not
       "interfaces"; the mapping between intefaces and addresses can be
       multi-valued in either direction.

       "localhost" means to listen on all protocol families supported by
       the SSH implementation on loopback addresses only.  Note: loopback
       addresses are defined in [RFC3330] for IPv4 and [RFC3513] for
       IPv6.

       "127.0.0.1" and "::1", while not really special cases for a
       normally configured system indicate listening on the loopback
       interfaces for IPv4 and IPv6 respectively.

---

Comments?

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 16 Feb 2005 15:19:54 +0100

> How about the following which separates the thoughts into a list.

The organization is clear, but it can be cut down a little.

>        protocol families supported by the SSH implementation.

Perhaps strike "from anywhere", the mechanism is not (on the surface)
about restricting *from where* connections are accepted, only *to
which* addresses.

>        multi-valued in either direction.

Delete "Note: ...". It's important that we choose the right word, but
the spec is not the right place to explain our choice in detail.

>        addresses are defined in [RFC3330] for IPv4 and [RFC3513] for

I think "... loopback addresses only [RFC3330, RFC3513]." is
sufficient reference. No other references in the text are introduced
with a "Note:".

>        interfaces for IPv4 and IPv6 respectively.

The "not really special" applies to "0.0.0.0" and "::" as well. Cut
it down to

         "127.0.0.1" and "::1" indicate listening on the loopback
         interfaces for IPv4 and IPv6 respectively.

I don't think we need to comment on which of the strings are "special"
and which are "normal", but if we want to do that, it should go into
the first paragraph.

Regards,
/Niels

---

From: der Mouse <[email-masked]>
Date: Wed, 16 Feb 2005 12:46:51 -0500 (EST)

>>        "interfaces"; the mapping between intefaces and addresses can
>>        be multi-valued in either direction.
> Delete "Note: ...".

Yeah.  I put that note in [brackets] when I wrote it because it was
intended for the list (to explain why I switched from "interfaces" to
"addresses"), not for the document.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 17 Feb 2005 05:22:50 -0800 (PST)

Hi,

I appreciate the quick reviews and suggestions.  If I don't hear any
disagreement on this proposal within ~24 hours, I'll use it and submit
the updated IDs to the repository.

===

       "" means that connections are to be accepted on all protocol
       families supported by the SSH implementation.

       "0.0.0.0" means to listen on all IPv4 addresses.

       "localhost" means to listen on all protocol families supported by
       the SSH implementation on loopback addresses only, [RFC3330] and
       [RFC3513].

===

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Feb 2005 13:15:39 -0500

>    passed in the open request.

Looks good overall, but there is an issue we should be aware of even if we 
decide not to make any change as a result.  The difference between 
addresses and interfaces has already been pointed out, and the text has 
been altered appropriately.  However, a similar issue applies to loopback 
addresses and interfaces -- they are not always bound together.  A host may 
have multiple loopback interfaces only one of which is assigned the 
canonical loopback address -- the others may have alternate-loopback, 
private-use, or even routable addresses.  Similarly, the loopback address 
may have been used on a physical interface, or (more likely), it may be 
possible to receive packets on the loopback address via a non-loopback 
interface.

We should be careful to specify exactly what we mean by "localhost", 
"127.0.0.1", and "::1".  Do we mean that the ssh server should bind to the 
loopback address, or that it should listen on all loopback interfaces, 
regardless of address?

---

From: der Mouse <[email-masked]>
Date: Thu, 17 Feb 2005 13:55:25 -0500 (EST)

> The difference between addresses and interfaces has already been
> pointed out, and the text has been altered appropriately.  However, a
> similar issue applies to loopback addresses and interfaces --

Well spotted.  I would have mentioned it myself when I brought up
address-vs-interface elsewhere if I'd noticed it.

Here too I think using "interfaces" is wrong.  However, in this case
I'm much less sure that using "addresses" is right.  For IPv6, there is
exactly one loopback address, and it is ::1.  But for IPv4, all of
127/8 is defined as loopback, and it's not clear whether "127.0.0.1"
should mean just listen on 127.0.0.1, or on all of 127/8 (which latter
is hard to do on many systems, and is not what most software does).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 17 Feb 2005 12:06:19 -0700

> is hard to do on many systems, and is not what most software does).

I would definitely say "127.0.0.1" should mean 127.0.0.1,
and "127.0.0.2" should mean 127.0.0.2

I would also vote for "localhost" meaning 127.0.0.1 for the
IPv4 protocol + canonical localhost address for any other
protocols.

Thanks,

Joseph

---

From: [email-masked] (Niels Möller)
Date: 17 Feb 2005 21:31:04 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> "127.0.0.1", and "::1".  Do we mean that the ssh server should bind to
> the loopback address, or that it should listen on all loopback
> interfaces, regardless of address?

As for IPv6, my reading of RFC3513 is that ::1 is the only localhost
address. One may be able to set up routing for other addresses so that
they behave the same way ::1, but I don't think that's anything an ssh
implementation should be required to know about. For IPv6, "localhost
interface" = "localhost address" = "::1" seems to be consistent with
the referenced RFC, so I don't think there's any ambiguity.

For IPv4, the entire block 127.0.0.0/8 is reserved for localhost
addresses. My feeling is that it should be sufficient, in practically
all cases, to listen on 127.0.0.1. In the uncommon case that there are
several configured loopback adresses, 127.0.0.1 *ought* to be one of
them.

If 127.0.0.x, x != 1, is a configured address, it may or may not make
sense to have the ssh server to listen on that address too, in
addition to 127.0.0.1. I can't make a strong and universal
recommendation either way, so I think this choice should be left to
the implementation. I would expect most implementation to treat
"localhost" and "127.0.0.1" as synonyms (within IPv4).

If we absolutely need to clarify it, we could say something like

  For IPv4, a large block, 127.0.0.0/8, is reserved for localhost
  addresses. Implementations MAY/SHOULD treat 127.0.0.1 as the only
  IPv4 localhost address. Listening on other addresses in this block,
  when "localhost" is requested, is OPTIONAL.

Regards,
/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Feb 2005 16:11:05 -0500

> the referenced RFC, so I don't think there's any ambiguity.

No; you're making the same mistake of confusing an interface with an 
address.  I believe that ::1 is the only loopback address; that is, it is 
the only address that means "the same machine".

A loopback _interface_ is one for which traffic sent on that interface is 
only received on that interface.  Several operating systems allow the 
creation of multiple of these, and you can assign them whatever address you 
want and they still behave the same way.  In some cases you can play games 
like setting up a loopback interface with a routable address, which is then 
reachable via TCP from outside the machine, even though it is not the 
address of any of the machine's physical interfaces.

This _does_ happen, and it has nothing to do with what network protocol 
you're running.  We had to work around this in AFS, to avoid advertising 
addresses of loopback devices.

I think we want to be clear that if the client says to listen on 
'localhost', the server SHOULD NOT listen on non-loopback addresses just 
because they happen to be the configured addresses of loopback interfaces.

---

From: [email-masked] (Niels Möller)
Date: 18 Feb 2005 09:38:41 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> A loopback _interface_ is one for which traffic sent on that interface
> is only received on that interface.  Several operating systems allow
> the creation of multiple of these, and you can assign them whatever
> address you want and they still behave the same way.

Is there any functional difference between

* creating two loopback interfaces, and assing them one address each,
  127.0.0.1 and 192.0.2.1.

* using a single loopback interface, with two assigned addresses,
  127.0.0.1 and 192.0.2.1.

In the second case, I guess one can set up a route saying that
192.0.2.1 is reachable via the localhost interface, and forward
packets received on other packets to the loopback interface, but I
don't see what one can achieve by doing that.

For ssh forwarding, the question is whether or it's desirable, in this
case, that ssh localhost forwarding listens 192.0.2.1. This is too
obscure to me. Why would anybody setup addresses and routing so that
packets are forwarded do an address on the loopback interface? Is the
point to treat some remote processes as if they were local? Then it
might make sense to have ssh treat them as local too.

I'm curiuos if you would like to explain this, but I feel we're

>        the SSH implementation on loopback addresses only, [RFC3330] and

This doesn't talk about interfaces, only addresses. For IPv6, that's
only one addrss (according to RFC3513). For IPv4 one have the choice
of either using only the canonical loopback address, or all configured
addresses in the entire loopback block. I don't think it matters much,
and can be left to the implementation. IPv4 addresses outside of the
127.0.0.0/8 block should never come into play.

A possible clarification is

        "localhost" means to listen on all protocol families supported
        by the SSH implementation, on their respective canonical
        loopback addresses only, [RFC3330] and [RFC3513].

>        interfaces for IPv4 and IPv6 respectively.

If we change this to say "address" instead of "interfaces", does that
make everybody happy? Like "0.0.0.0" and "::", these really aren't
special cases.

/Regards,

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Feb 2005 09:16:33 -0500

On Fri, 2005-02-18 at 03:38, Niels M?ller wrote:
> This is too
> point to treat some remote processes as if they were local? 

No.  This is a high-availability hack generally used for cisco router 
management addresses and also for multi-homed high value servers trusted
to participate in an IGP (OSPF/RIP/...), to avoid single points of failure 
and to allow them to be moved around in the site topology without being 
renumbered.  The hosts inject one or more /32 routes into the local routing 
system, and the routers find the best path to the hosts.

The additional address is put on a virtual interface -- often lo0 on unixes --
so that failure/removal of one of the physical interfaces doesn't cause it to 
disappear.  solaris 10 contains a virtual "vni" interface driver 
specifically so you don't have to put these addresses on lo0 where they
might be mistaken for a trusted loopback-only address.

> Then it might make sense to have ssh treat them as local too.

no, these are real externally visible addresses.

						- Bill

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 18 Feb 2005 06:34:08 -0800 (PST)

Hi,

I've submitted the core IDs to the ID Editor.  Notes on the new versions:

Now using xml2rfc 1.28, the prior set of IDs were created using 1.26.

[ARCH] - included section to explain the use of 'field' and "value" in
Conventions section 3. - duplicated in all other IDs.

[ARCH] - included "Traffic Analysis" section.

[NUMBERS] - Removal of Message numbers 30, 31 and 60 from Section 4.1.2.

[NUMBERS] - Message Number future assignments in 4.1.3.

[NUMBERS] - Explanation of kex names duplicated from [TRANS] in 4.10.

[CONNECT] - assignment of 'address to listen' in 7.1.

[TRANS] - Explanation of kex names in 6.5.

[TRANS] - Removal of SPKI stuff in 6.6.

[USERAUTH] - banner message nit in 5.4.

All - various spelling and grammar corrections along with 'field' and
"value" modifications.

For those who can't wait for them to show up in the ID repository, I've
placed them here:
  http://www.employees.org/~lonvick/secsh-wg/2005-feb-18/
This directory also contains the 'diffs' from prior versions as well as
the xml.

Thanks,
Chris