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]> > Sent: Tuesday, July 22, 2025 1:48 AM > To: [email protected] > Cc: 'Internet Area' <[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] To unsubscribe send an email to [email protected]
