FreeBSD and dual mode sockets about scala-native HOT 11 OPEN

Another useful link: https://lwn.net/Articles/688462/

From OpenBSD inet6(4) man page:

For  security  reasons,	OpenBSD	 does  not  route  IPv4	 traffic to an
       AF_INET6	socket,	and does not support IPv4 mapped addresses, where IPv4
       traffic	is  seen  as  if  it  comes  from   an	 IPv6	address	  like
       "::ffff:10.1.1.1".   Where  both	 IPv4  and IPv6	traffic	need to	be ac-
       cepted, bind and	listen on two sockets.

From FreeBSD inet6(4) man page:

   Interaction between IPv4/v6 sockets
     By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets.  The
     default behavior intentionally violates RFC2553 for security reasons.
     Listen to two sockets if you want to accept both IPv4 and IPv6 traffic.
     IPv4 traffic may be routed with certain per-socket/per-node
     configuration, however, it is not recommended to do so.  Consult ip6(4)
     for details.

     The behavior of AF_INET6 TCP/UDP socket is documented in RFC2553.
     Basically, it says this:
     •   A specific bind on an AF_INET6 socket (bind(2) with an address
         specified) should accept IPv6 traffic to that address only.
     •   If you perform a wildcard bind on an AF_INET6 socket (bind(2) to IPv6
         address ::), and there is no wildcard bind AF_INET socket on that
         TCP/UDP port, IPv6 traffic as well as IPv4 traffic should be routed
         to that AF_INET6 socket.  IPv4 traffic should be seen as if it came
         from an IPv6 address like ::ffff:10.1.1.1.  This is called an IPv4
         mapped address.
     •   If there are both a wildcard bind AF_INET socket and a wildcard bind
         AF_INET6 socket on one TCP/UDP port, they should behave separately.
         IPv4 traffic should be routed to the AF_INET socket and IPv6 should
         be routed to the AF_INET6 socket.

     However, RFC2553 does not define the ordering constraint between calls to
     bind(2), nor how IPv4 TCP/UDP port numbers and IPv6 TCP/UDP port numbers
     relate to each other (should they be integrated or separated).
     Implemented behavior is very different from kernel to kernel.  Therefore,
     it is unwise to rely too much upon the behavior of AF_INET6 wildcard bind
     sockets.  It is recommended to listen to two sockets, one for AF_INET and
     another for AF_INET6, when you would like to accept both IPv4 and IPv6
     traffic.

     It should also be noted that malicious parties can take advantage of the
     complexity presented above, and are able to bypass access control, if the
     target node routes IPv4 traffic to AF_INET6 socket.  Users are advised to
     take care handling connections from IPv4 mapped address to AF_INET6
     sockets.

from scala-native.

Having documented references is beyond gold and a real time save.

I propose that at the least I/we put a section in the "Setup" doc describing
FreeBSD support referring to the FreeBSD man page referenced above.
Probably stating that OpenBSD acts similarly.

I think, from brief current experiments, that BSD-based macOS 14.2 follows the IETF specification.
I will have to check the macOS man page next time I have that system booted. Oh for a KVM switch and
solar electricity.

I believe that Scala Native follows the IETF RFC and any deviation is unintentional and a defect/bug.

I propose that SN continue this way for the foreseeable future. What is the sense of the meeting
(participants in this Issue)?

from scala-native.

Thank you for creating this Issue. It is bigger than a breadbox.

I recommend you delete the two "battlebrow" URLs so that SN developers reading
this issue do not fall into a situation where they are reading actual JDK code. Reading
the JDK code would go against the SN license.

from scala-native.

Status note:

I read the referenced 20+ year old draft rfc and a series of proposed standard rfc which came after it.
I am not sure if I got to a recent final rfc. The later RFCs continued to allow IPv4-maped-IPv6 addresses.

The important/relevant point is that the draft RFC seems to have motivated some BSD developers to
take action.

I suspect that action is at the OS level and not at the JDK level.

The latest JDK "Networking Properties" API documentation I could find with a 20-second Google search
was for Java 20. It says:

java.net.preferIPv4Stack (default: false)
If IPv6 is available on the operating system the underlying native socket will be, by default, an IPv6 socket which lets applications connect to, and accept connections from, both IPv4 and IPv6 hosts. However, in the case an application would rather use IPv4 only sockets, then this property can be set to true. The implication is that it will not be possible for the application to communicate with IPv6 only hosts.

Java 8 API says almost, if not exactly, the same thing.

I will have to check what the C library on FreeBSD & macOS allow for IPv4-mapped-IPv6 addresses.
I do not want to prejudice the discussion, but I would be astonished if they do not allow such.

from scala-native.

Of course the action has been taken at the OS level. net.inet6.ip6.v6only is a sysctl at the OS level. If the OS prohibits the use of such addresses, no library can overcome this limitation (otherwise it would exit the created security boundary).

OpenJDK 11+ don't have different behaviors on other platforms, as I said this is specific to all BSD ports (and not well documented).

from scala-native.

Here you can find some additional context: https://lists.freebsd.org/pipermail/freebsd-net/2013-June/035858.html

BTW, I think the SN re-implementation of the java network API relies on IPv4-mapped IPv6 addresses, too, creating just one socket. It would be nice if it was the first java implementation to create two different unix sockets to handle the two protocols ;-)

from scala-native.

Notes:

• net.inet6.ip6.v6only is 0 on both my FreeBSD 14.mumble system and my macOs 14.latest systems.
  ssh, a non-Java program, seems to work just fine with IPv4-mapped-IPv6 addresses. A data point, not
  definitive proof.

• I read the IPv6 section of the FreeBSD (developer's handbook) and say nothing prohibiting or deprecating
  IPv4-mapped-IPv6 addresses. There may be something in the fine print, but no thumb-in-the-eye.

from scala-native.

• net.inet6.ip6.v6only is 0 on both my FreeBSD 14.mumble system and my macOs 14.latest systems.

Did you add the following setting to /etc/rc.conf or a direct sysctl into /etc/sysctl.conf? Otherwise it's not possible that the default is 0.

% fgrep ipv6_ipv4mapping /etc/defaults/rc.conf
ipv6_ipv4mapping="NO"           # Set to "YES" to enable IPv4 mapped IPv6 addr

ssh, a non-Java program, seems to work just fine with IPv4-mapped-IPv6 addresses. A data point, not
definitive proof.

sshd opens two sockets as most unix daemons do (especially considering that OpenSSH is developed by OpenBSD devs :-)), it doesn't rely on IPv4-mapped IPv6 addresses:

% sockstat | fgrep sshd | fgrep '*'
root     sshd       16069 3  tcp6   *:22                  *:*
root     sshd       16069 4  tcp4   *:22                  *:*

And this is the ssh client:

% ssh ::ffff:127.0.0.1
ssh: connect to host ::ffff:127.0.0.1 port 22: Invalid argument
% sysctl net.inet6.ip6.v6only=0
net.inet6.ip6.v6only: 1 -> 0
% ssh ::ffff:127.0.0.1
The authenticity of host '::ffff:127.0.0.1 (::ffff:127.0.0.1)' can't be established.
...

from scala-native.

Thank you for the URLs.

I am trying to keep an open & inquiring mind.

I am not certain that there is a problem here. Perhaps the URL put it succinctly "debatable safety."
Then again, as soon as someone uses the word "security", one must go to extra lengths to convince
oneself and the world that there is not a real problem.

The reason that we created this issue is so that it and the need to test also test on FreeBSD & macOS with Java >=11
can be kept in mind. This issue seems to be doing its job.

re:

It would be nice if it was the first java implementation to create two different unix sockets to handle the two protocols ;-)

As the author of the code in question, I am probably disqualified to judge and must seek concrete evidence.

I have to swap over to another task now. When I have another time slice here, I will have to read the Java API for
ServerSocket yet again.

If there are know-but-to-a-few OS differences and we can characterize them, it would be friendly for SN to
point them out (probably in a *BSD section for IPv6 support). Save both users and some future maintainer/contributor
chasing OS-dependent will-'o-the-wisps.

I think the author of the posted URL described the tension between "standards compliance" and "idiosyncratic security fixes", especially when the veracity of the purported "security" issue is hard to affirm or bring to consensus.

from scala-native.

Yes, the severity of the security issue is subjective, I fully agree, but the result is that some OSes decided for more restrictive defaults, and others completely removed such feature (given that the same result can be achieved with what was already provided by the unix socket API).
That's all, this issue is here to better document these differences, so that they can be taken into consideration when portability choices have to be made.

from scala-native.

That's all, this issue is here to better document these differences

I think that is somewhere between a big gain and essential. Thank you for taking the initiative to
report what you found in the original PR and to create this issue.

When I return to this Issue, I will attempt to play the "What changed on what OS and which versions" game.
SN can not document every OS variant, but we. IMHO, can at least try to document the tiger traps.

More as I discover it.

from scala-native.