Suggestion: Use well-known source port 546 for DHCPv6 requests
asked 2015-02-21 14:44:17 +0200
The DHCPv6 client in SailfishOS will use a random ephemeral source port for its outgoing DHCPv6 messages. This is legitimate per RFC 3315, however it does trigger a bug in certain DHCPv6 servers, which are incorrectly re-using this port when forming their DHCPv6 responses, rather than using port 546 which is the one mandated by section 5.2 of the RFC, and of course also the port where the SailfishOS' DHCPv6 client correctly listens for responses.
The following packet capture shows this happening. In the first packet, the SailfishOS' DHCPv6 client uses source port 45152 in its initial DHCPv6 Solicit message. The second packet shows how the buggy DHCPv6 server (in this case, a Cisco EPC3940L cable modem / eRouter) re-uses port 45152 as the destination port of its DHCPv6 Reply message. The third packet shows the Linux kernel on the SailfishOS rejects this packet with an ICMPv6 error because there's nothing listening on port 45152.
13:04:04.955691 IP6 (hlim 1, next-header UDP (17) payload length: 66) fe80::5256:a8ff:fe01:7b39.45152 > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=5584c5 (elapsed-time 0) (rapid-commit) (client-ID hwaddr/time type 1 time 477589086 5056a8017b39) (IA_NA IAID:2818669369 T1:0 T2:0) (option-request DNS-server DNS-search-list SNTP-servers))
13:04:04.983617 IP6 (hlim 128, next-header UDP (17) payload length: 128) fe80::1a55:fff:febb:2c3.dhcpv6-server > fe80::5256:a8ff:fe01:7b39.45152: [udp sum ok] dhcp6 reply (xid=5584c5 (client-ID hwaddr/time type 1 time 477589086 5056a8017b39) (IA_NA IAID:2818669369 T1:900 T2:1350 (IA_ADDR 2a02:fe0:c410:c430::2 pltime:1800 vltime:3600)) (DNS-server 2a02:fe0:1:2:1:0:1:110 2a02:fe0:1:2:1:0:1:111) (rapid-commit) (server-ID hwaddr type 1 18550fbb02c3))
13:04:04.983922 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 176) fe80::5256:a8ff:fe01:7b39 > fe80::1a55:fff:febb:2c3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable port, fe80::5256:a8ff:fe01:7b39 udp port 45152
This exchange repeats for a while, until the SailfishOS DHCPv6 client gives up retrying. Because the DHCPv6 Reply is sent to an unexpected port, the SailfishOS DHCPv6 client never sees it.
While it is quite clear that the DHCPv6 client in SailfishOS is doing nothing illegal according to the RFC, I think using the well-known DHCPv6 client port (546) instead of random ephemeral ports when forming DHCPv6 requests would lead to a more robust implementation overall, which has a higher chance of success when faced with buggy DHCPv6 servers found in the wild.
I agree! The client should be "nice" to buggy servers.
jzrz ( 2015-02-21 15:23:00 +0200 )editI disagree, client(s) shouldn't trust and provide workarounds for buggy servers in regards to internet-protocols cause this potentially raises security and privacy concerns for using them.
foss4ever ( 2015-02-21 15:48:52 +0200 )editjjaone, could you elaborate on how using the well-known DHCPv6 client port as the source port for outgoing DHCPv6 requests could possibly "raise security and privacy concerns"? It's not like it's a secret that the DHCPv6 client is indeed a DHCPv6 client regardless of which source port it uses - the UDP payload is a DHCPv6 request transmitted in cleartext, after all.
tore ( 2015-02-21 15:54:47 +0200 )edit@tore Could you elaborate on how trusting or providing workarounds for buggy or misbehaving servers/services is not a potential security/privacy issue?
Using fixed well-kbown ports are additionally nor always the best solution; e.g. SSH servers that listen standard port, expose themselves to DOS abd brute-force attacks but changing the port helps somewhat. (not directly related to this request, but I hope u see my point).
foss4ever ( 2015-02-21 16:06:07 +0200 )edit@jjaone, well, the only piece of information that would be divulged by changing the SailfishOS DHCPv6 clients from using random source ports to using 546, is to give another hint to the DHCPv6 server that there is a DHCPv6 client listening on that port. Doing so is not problematic, because it is already a well known fact that all DHCPv6 clients listens on port 546/udp. See the RFC.
Even if there was no well known port for DHCPv6 clients, you would still have to to divulge the DHCPv6 client's listening port to the DHCPv6 server. Otherwise, it would have no way of knowing which port to address its responses to.
Your analogy to SSH servers doesn't fit, because in that case, you're also changing the port the SSH server actually listens to connections on. This does not apply here; DHCPv6 clients always listen on port 546/udp - that's the only way they can implement the RFC correctly. SailfishOS' DHCPv6 client is no exception:
Therefore, changing the source port of the outbound DHCPv6 requests will not make any difference with regards to the possibility of the DHCPv6 client in SailfishOS being scanned or attacked from the Internet.
tore ( 2015-02-21 17:40:42 +0200 )edit