Thanks, Dave, I remember you mentioning this at IETF 123 – I should have been better about following up.
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)? Presumably this is an application on 10.1.1.1 running a UDP service on port 1234. How would the host firewall on 10.1.1.1 have to be configured to allow traffic to this service? 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? In other words, Reply Option 1 would work with host firewalls while Reply Option 2 would not? Nate From: Dave Thaler <[email protected]> Sent: Tuesday, November 4, 2025 07:43 To: [email protected] Cc: 'Internet Area' <[email protected]> Subject: [Int-area] draft-ietf-intarea-multicast-application-port-01 interaction with host firewalls I just reviewed draft-ietf-intarea-multicast-application-port-01, specifically the diffs from draft-karstens-intarea-multicast-application-port-02. Some text in section 2 was updated and I'm listed in the Acknowledgement section. However, I I just reviewed draft-ietf-intarea-multicast-application-port-01, specifically the diffs from draft-karstens-intarea-multicast-application-port-02. Some text in section 2 was updated and I'm listed in the Acknowledgement section. However, I don't think my comments are sufficiently addressed yet. I said: > -----Original Message----- > From: Dave Thaler > <[email protected]<mailto:[email protected]>> > Sent: Tuesday, July 22, 2025 1:48 AM > To: [email protected]<mailto:[email protected]> > Cc: 'Internet Area' <[email protected]<mailto:[email protected]>> > Subject: draft-karstens-intarea-multicast-application-port-02 interaction > with host > firewalls > > Putting on the list a comment I made in the meeting, and adding more info > too... > > Section 2 says: > > The REQUESTED port may be used as a source port if the application > > exclusively uses multicast messages. If any application messages are > > unicast, then a dynamic port should be used as the source port. This > > allows receivers to know which port to send replies to. > > The context of my comment is applications that do some sort of multicast > discovery > where a multicast message is sent to solicit one or more unicast replies. > > My comment in the meeting is that the text in section 2 requires the app use a > separate socket for the reply (at least on some unmodified platforms). > That requirement is new and so should be stated explicitly. > > After I made the comment, it also occurred to me that this restriction may > also cause > problems with some host firewalls. Specifically, I suspect some will simply > drop the > unicast reply, breaking multicast discovery mechanisms if this document is > implemented with the section 2 restriction. > > That is, I believe some host firewalls will filter by the unicast source port > == the > multicast destination port that went outbound. So I would recommend > discussing that > explicitly in the document, since I'm afraid the stated restriction might > cause breakage. > > (And if you do add text about host firewalls, consider referencing IAB RFC > 7288.) > > Dave Here's the specific exchange in question: Request (using IPv4 as an example, though same for IPv6): 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 option 2: Source: 10.2.2.2:5678 (using a separate socket per sec 2 para 3) Dest: 10.1.1.1:1234 The problem is that reply option 2 gets dropped by the receiver since the host firewall does not see it as a reply to the request, due to the port being different. When the request is sent, the sender's post firewall allows replies from any request (since it knows the dest address is multicast), but still constrains the port, since it has no knowledge that the port is special. This is how many host firewalls work, and this is what needs to be considered in the draft to explain the effects in the real world. Reply option 1 would get through the host firewall fine, which is why apps/protocols use that today (independent of the port), but the draft disallows this, which I believe would break existing deployments. So I still don't understand how this proposal can work in the real world in the presence of uniquitous host firewalls of this sort. Looking forward to discussing this in the meeting today. Dave _______________________________________________ Int-area mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ________________________________ 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]
