kern/55066: KEYDEBUG_MATCH natt port logging

[frchuckz%gmail.com@localhost]

>Number:         55066
>Category:       kern
>Synopsis:       port numbers printed in network byte order instead of host byte order
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 12 17:20:00 +0000 2020
>Originator:     Chuck Zmudzinski
>Release:        NetBSD 9.99.49
>Organization:
	NetBSD User 
>Environment:
	
	
System: NetBSD ave 9.99.49 NetBSD 9.99.49 (XEN3_DOMU) #0: Thu Mar 12 03:01:46 UTC 2020 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/xen/compile/XEN3_DOMU amd64
Architecture: x86_64
Machine: amd64
>Description:
When debugging using sysctl net.key.debug=8 which enables KEYDEBUG_MATCH
logging, the port numbers are printed in network byte order which
complicates debugging because the human readable port and service
numbers are in host byte order. This is also inconsistent with the way
port numbers are logged with the IPSEC_DEBUG kernel compile option set.   
>How-To-Repeat:
Set sysctl net.key.debug value to 8 and configure the kernel logging
level to debug, then configure an IPSEC connection that	uses NAT-T
and view the logs. One will see the port number for NAT-T is printed
not as the human readable port/service number of 4500 but htons(4500)
or 37905. Optionally, one can also compile and run a kernel with the
IPSEC_DEBUG option set and see the inconsistency in logging the NAT-T
port numbers because the ports will be printed in host byte order
from the IPSECLOG macros, but in network byte order from the 
KEYDEBUG_MATCH macros. N.B.: This will create a very verbose log
with these logging and debugging settings, so don't forget to revert
the logging and debugging settings after testing.

I saw this problem when debugging a port of OpenBSD's IKEv2
iked daemon to NetBSD, but it should also be seen with any IPSEC
connection through a NAT box configured using racoon or any other
IKEv1 or IKEv2 daemon.
  
>Fix:
The fix is trivial.
Applyng this patch to the current version of src/sys/netipsec/key.c
fixes the problem:

--- key.c.orig	2020-03-12 11:53:42.491524911 -0400
+++ key.c	2020-03-12 12:02:02.558350963 -0400
@@ -4770,7 +4770,7 @@
 	case PORT_STRICT:
 		if (port1 != port2) {
 			KEYDEBUG_PRINTF(KEYDEBUG_MATCH,
-			    "port fail %d != %d\n", port1, port2);
+			    "port fail %d != %d\n", ntohs(port1), ntohs(port2));
 			return 1;
 		}
 		return 0;
@@ -4822,9 +4822,9 @@
 		KEYDEBUG_PRINTF(KEYDEBUG_MATCH,
 		    "addr success %s[%d] == %s[%d]\n",
 		    (in_print(s1, sizeof(s1), &sin1->sin_addr), s1),
-		    sin1->sin_port,
+		    ntohs(sin1->sin_port),
 		    (in_print(s2, sizeof(s2), &sin2->sin_addr), s2),
-		    sin2->sin_port);
+		    ntohs(sin2->sin_port));
 		break;
 	case AF_INET6:
 		sin61 = (const struct sockaddr_in6 *)sa1;	

>Unformatted: