tlsport & ntpport

[Richard Laager]

On 2/2/19 6:39 PM, Gary E. Miller via devel wrote:
> Yo Richard!
> 
> On Sat, 2 Feb 2019 17:52:57 -0600
> Richard Laager via devel <devel at ntpsec.org> wrote:
> 
>> On 2/2/19 7:22 AM, Achim Gratz via devel wrote:
>>> Eric S. Raymond via devel writes:  
>>>> *tlsport XXX* Contact the NTS-KE server on TCP port XXX.
>>>>
>>>> *ntpport YYY* Request an NTPD server on UDP port YYY.
>>>>
>>>> Can anyone explain to me a case in which these are not
>>>> equivalent to expcit port prefixes on a server, ask, re require
>>>> address?  
>>
>> They're not. Do the port suffixes on the server/ask/require instead.
> 
> Except the standard says otherwise.  The addresses specifically exclude
> the port.  Yes we can translate our config file into the Proposed RFC
> format, but every translation adds complexities, and potential errors.
> 
> Directly mapping the config to the RFC makes testing and validation
> much easier.  It is also common in other SSL/TLS implementations.

I disagree. Specifying server:port together is the common way.

> And we still have the wonderfull confusion that both IPv6 and port
> numbers use colons.  That is a support nightmare...

Yep, that's a pain. But it's a pain that is standard and has a standard
answer used everywhere: [address]:port

> But what if you do not care about the address?  Just the port?  For
> firewall and/or NAT reasons.
This is a good point that I had not considered.

Here are some examples for discussion:

1: ask ntp.example.com
2: ask ntp.example.com:10123
3: ask 192.0.2.1
4: ask 192.0.2.1:10123
5: ask 2001:DB8::1
6: ask [2001:DB8::1]
7: ask [2001:DB8::1]:10123

There may be a question about whether #5 is allowed.

And the question would be how to deal with a request for a port only.
There seem like two ways to allow that:

8: ask 10123
9: ask :10123

#9 is not ambiguous with anything, but looks weird and is almost
ambiguous with #5, as ::10123 is an IPv6 address (albeit not one that is
likely to be reachable).

#8 is probably not ambiguous in practice, though technically it is a
valid domain name (albeit one that requires a DNS search path).

Personally, I'd probably disallow #5, and I'd choose #9 and not #8. So
we have these options:

1: ask ntp.example.com
2: ask ntp.example.com:10123
3: ask 192.0.2.1
4: ask 192.0.2.1:10123
6: ask [2001:DB8::1]
7: ask [2001:DB8::1]:10123
9: ask :10123

For parsing:
  If the value has a colon:
    # We are considering #2, #4, #6, #7, and #9.
    If the value starts with a bracket:
      # We are considering #6 and #7.

      The part in brackets is an IPv6 address. #6 done && #7
      If there was a colon after the brackets, get the port. #7 done
      Stop.

    # We are still considering #2, #4, and #9.
    Split on the colon. The part after the colon is the port.
    If there is nothing left, stop. #9 done
    Continue with the part before the colon only.

  # At this point, #2 looks like #1 and #4 looks like #3.
  # We are considering #1 and #3.

  If the value is an IPv4 address:
    It is an IP addres. #3 done.
    Stop.
  It is a hostname. #1 done.

FWIW, if you just use an existing URL parsing library, it may just
support #9 out of the box. Python's does, for example.

$ python3
>>> import urllib.parse
>>> urllib.parse.urlparse("nts://:1234").port
1234

>>> urllib.parse.urlparse("nts://ntp.example.com:1234").hostname
'ntp.example.com'
>>> urllib.parse.urlparse("nts://192.0.2.1:1234").hostname
'192.0.2.1'
>>> urllib.parse.urlparse("nts://[2001:DB8::1]:1234").hostname
'2001:db8::1'

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/8a76ef8a/attachment.bin>