port forwarding trouble

[Darren Tucker]

Sergio Gelato wrote:
> * Darren Tucker [2005-08-05 00:41:37 +1000]:
> 
>>Sergio Gelato wrote:
>>
>>>* Frederik Eaton [2005-08-02 17:39:59 +0100]:
>>>
>>>>Also, I don't think that the "host at port" syntax suggested in the bug
>>>>comments is a good idea. 
>>>
>>>At the very least it should be port at host. There is precedent for that,
>>>e.g. in FlexLM LM_LICENSE_FILE environment variables.
>>
>>Why is that better the host at port?  I would bet there's precedent for 
>>that somewhere too.
> 
> 
> Because "@" traditionally stands for the preposition "at", and most
> people find it more natural to use the host name as a scope identifier
> than the port number (maybe also because e-mail addresses have
> the host name on the right side of the @ sign).

As a mnemonic is still works ("host foo.far.com at port 22").

> And while we are comparing with e-mail addresses: how about host!port ?

I don't mind it (as long as it's not a valid char in a host name.. what 
are the rules these days?), but see below.

[...]
>>>I'm not sure about URLs, but various tools simply require square
>>>brackets around the IPv6 address, as in
>>>	[0:1:2:3:4:5:6:7]:port
>>
>>That would be OK for new entries but it's not backward compatible with 
>>existing known_hosts files.
> 
> That means the code to parse existing known_hosts files needs to be a
> little more complex. New entries should obviously use the less ambiguous
> notation.

I had to come up with a heuristic for this for another reason (sshd's 
ListenAddress is slightly broken for bare IPv6 addresses) which might be 
enough:

if the string doesn't contain "[]" and contains 2 or more ":"
	it's a bare IPv6 address
else
	do existing tests in misc.c:hpdelim()

>>Once you add an optional ":port" I don't see how it's possible to 
>>reliably distinguish between IPv6 addresses created by old versions and 
>>host:port indentifiers created by new versions.
> 
> Don't add an optional ":port" for IPv6 address literals, then; make the
> [v6addr]:port notation mandatory in such cases. 

That's reasonable since the notation with the port spec isn't backward 
compatible anyway.

> If you've already allowed v6addr:port, then the ambiguity is with us no 
> matter what.

I don't think that notation is permitted anyplace.  It's not documented, 
anyway.

> For interpreting existing known_hosts files, one could
> agree that (a) the now-deprecated notation causes a warning to be
> emitted, and (b) an ambiguous string is interpreted as matching
> either interpretation, e.g. ::1:22 is equivalent to [::1]:22,[::1:22] .

[...]
>>They're host keys, I don't see how the identifiers could be confused 
>>with a user. There's no reference to users at all in known_hosts.
> 
> The software wouldn't be confused, but humans who edit the known_hosts 
> file might.

Since it's always numeric I can't see that being a big problem.

I'd like to use the same format everywhere if possible, but not if it 
means breaking a gazillion existing known_hosts files.

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