Dave, We discussed this in the meeting briefly, but just to make sure it’s covered, the reason that Reply Option 1 is prohibited by section 2 is that if multiple applications were using port 8738, then any unicast reply would be distributed to applications using a round-robin mechanism (at least in Linux). Here’s the exchange for this:
Request: Source: 10.1.1.1:1234 (not using 8738 because the application also sends unicast messages, per sec 2 para 2) Dest: 224.1.1.1:8738 Reply option 1: Source: 10.2.2.2:8738 (this violates the current wording of section 2, so the current draft disallows this) Dest: 10.1.1.1:1234 Reply to Reply option 1: Source: 10.1.1.1:1234 Dest: 10.2.2.2:8738 <== Which application gets it? Returning now to the firewall discussion, if I’m remembering correctly about how some of these host firewalls work, the user can configure the firewall to support any traffic for designated applications. Some of them require the user to proactively add applications to the approved list, while others will prompt the user to do this. Would one solution to this be that the user should configure the host firewall appropriately? If so, it seems like it covers both the first (Request and Reply Option 2) and second (Reply Option 2 only) scenarios. If the user does not configure their firewall correctly, then both of these scenarios will fail. The second scenario isn’t relevant to the I-D, but it is a valid scenario that host firewalls would want to support. Furthermore, it is useful to see that both scenarios are failing in the same way – that is, the proposal in the I-D isn’t any worse. Another solution might be that firewalls should automatically allow the Request / Reply Option 2 scenario by allowing incoming replies directed to the source address/port of the Request. Request: Source: 10.1.1.1:1234 (not using 8738 because the application also sends unicast messages, per sec 2 para 2) Dest: 224.1.1.1:8738 Reply option 2: Source: 10.2.2.2:5678 (using a separate socket per sec 2 para 3) Dest: 10.1.1.1:1234 However, I’m not sure this is a good idea as it would be a great protocol to attack the host with: 1) Request message multicasts availability of a command & control server running on the host and punches a hole through the firewall and 2) Reply message from attacker goes through firewall and begins C&C session. So, it seems like the best solution would be to have the user manually configure the firewall to support the application, which I believe is what they would have to do now anyway. Does that make sense to you? If so, what do you think? Thanks! Nate From: Dave Thaler <[email protected]> Sent: Tuesday, November 4, 2025 10:40 To: Karstens, Nate <[email protected]>; [email protected] Cc: 'Internet Area' <[email protected]> Subject: RE: [Int-area] draft-ietf-intarea-multicast-application-port-01 interaction with host firewalls Nate Karstens wrote: > Looking at the example exchange (Request and Reply Option 2, as Reply Option 1 is currently prohibited), > how would the firewall handle this if we remove the Request message and just have Reply Option 2 > (we’ll Nate Karstens wrote: > Looking at the example exchange (Request and Reply Option 2, as Reply Option > 1 is currently prohibited), > how would the firewall handle this if we remove the Request message and just > have Reply Option 2 > (we’ll keep its name even though it’s no longer a reply)? It would be dropped since it's an unsolicited inbound message. Only the Request makes it solicited and allowed. > Presumably this is an application on 10.1.1.1 running a UDP service on port > 1234. Yes. > How would the host firewall on 10.1.1.1 have to be configured to allow > traffic to this service? It would have to be configured to be a "server" on 1234, and allow unsolicited inbound traffic. > Or is it more that you’re pointing out that normally the Request message > would cause the > host firewall on 10.1.1.1 to allow replies back to port 1234 as long as the > original packet’s > destination port is used as the source port of the reply? Right. > In other words, Reply Option 1 would work with host firewalls while Reply > Option 2 would not? Right. Dave ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
