OSX mDNSResponder abriendo todos los puertos en Billion

Recientemente cambié mi enrutador por un Billion 7800VDOX, y noté algunos intentos de conexión a mi iMac desde direcciones externas. En la investigación descubrí que se había abierto un puerto uPnP en el enrutador con un rango de puertos 0-0 (interno y externo). Esto tiene el efecto, verificado con un escáner de puertos externo, de abrir TODOS los números de puerto en el enrutador y dirigirlos a El iMac. Eliminé la asignación y ejecuté Wireshark y capturé una solicitud de dirección externa al mismo tiempo que se restableció la asignación.

Frame 496: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: Apple_d0:7e:eb (d4:9a:20:d0:7e:eb), Dst: BillionE_cb:49:27 (00:04:ed:cb:49:27)
Internet Protocol Version 4, Src: 192.168.1.131, Dst: 192.168.1.254
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5351 (5351)
Source Port: 5353
Destination Port: 5351
Length: 68
Checksum: 0x8527 [validation disabled]
[Stream index: 0]
Port Control Protocol, Map Request
Version: 2
0... .... = R: Request
.000 0001 = Opcode: Map (1)
Reserved: 0
Requested Lifetime: 7200
Client IP Address: ::ffff:192.168.1.131
Map Request
    Mapping Nonce: f88237920f8cd6c0a3765f39
    Protocol: 6
    Reserved: 0
    Internal Port: 9
    Suggested External Port: 0
    Suggested External IP Address: ::ffff:xxx.181.81.112

Esto fue precedido por una solicitud SOAP para obtener la dirección IP externa del enrutador. Comprobando el puerto de origen (5353) con lsof encontré que es propiedad de mDNSResponder.

Mi suposición sobre lo que está sucediendo es que mDNSResponder está usando esto solo para obtener la dirección IP externa del enrutador, y lo hace usando una solicitud supuestamente inofensiva para mapear el puerto 0, que debería ser un puerto no válido. Sin embargo, el enrutador Billion trata esto como, ya sea por diseño o error de programación, como una solicitud para abrir todos los puertos. Desactivar uPnP en el enrutador resuelve el problema (aunque, como se señaló, esto no es realmente uPnP).

Alguien tiene alguna otra sugerencia?

El paquete que capturó muestra una solicitud de asignación de puerto del Protocolo de control de puertos (PCP: el sucesor de seguimiento de estándares IETF a NAT-PMP). El puerto del cliente para la asignación solicitada es 9 / TCP. El cliente no tiene ninguna sugerencia sobre cuál debería ser el puerto externo, por lo que deja el campo de puerto externo sugerido establecido en cero. IETF RFC 6887, que define PCP, deja en claro que cero significa "sin sugerencia" en este campo.

Creo que quien implementó PCP para este enrutador Billion leyó mal el RFC. Verá, en algunos casos muy limitados y bien definidos, un cero en el campo OTROS puertos podría significar "todos los puertos". Al igual que cuando la vida útil solicitada para esta solicitud de asignación es cero, un puerto de cliente cero significaría "eliminar todas las asignaciones para todos los puertos en la dirección IP de este cliente".

Pero nuevamente, en el campo de puerto externo sugerido, se supone que cero siempre significa "sin sugerencia". Nunca se supone que significa "todos los puertos" en este campo.

Por lo tanto, parece bastante claro que ha encontrado un error de PCP en este enrutador Billion.

Otra cosa extraña aquí es el puerto del cliente. Tradicionalmente, 9 / TCP es el discardpuerto del servicio, pero el discardservicio está en desuso, por lo que no estoy seguro de quién lo ejecutará más o por qué algo solicitaría una asignación de puerto para él.

En cuanto a por qué mDNSResponder está enviando estas solicitudes, es simplemente porque mDNSResponder actúa como el demonio PCP / NAT-PMP / UPnP en macOS además de sus tareas habituales de resolución de mDNS, DNS-SD y DNS. Cuando cualquier proceso en macOS activa el sistema para solicitar una asignación de puertos del enrutador, siempre es tarea de mDNSResponder crear y enviar los paquetes de solicitud de asignación de puertos reales.