Dave, Thanks for your feedback, this is really helpful!
Please see the replies below… Cheers, Nate From: Dave Thaler <[email protected]> Sent: Monday, January 26, 2026 1:28 PM To: 'Wassim Haddad' <[email protected]>; [email protected]; [email protected]; [email protected] Subject: [Int-area] Re: WG Last Call: draft-ietf-intarea-multicast-application-port-03 (Ends 2026-02-09) 1) Contradiction in node requirements Abstract says: > This method does not require > modification to existing protocol stacks, though recommended updates > to make the port easier to use are included. The above language ("recommended", 1) Contradiction in node requirements Abstract says: > This method does not require > modification to existing protocol stacks, though recommended updates > to make the port easier to use are included. The above language ("recommended", "does not require") implies a SHOULD. However, section 3 contradicts that and instead says: > Hosts SHALL require applications using this port to use it non- > exclusively. (plus various other SHALL statements about hosts). This especially matters if BCP 220 is updated to reference this document. [Karstens] I can see how this would seem contradictory. This is a bit of a grey area because we would want someone looking at this document to interpret these as requirements, but that the advantage to this overall approach is that it can be used even in environments that have not been updated yet. I would propose changing the last sentence of the abstract as follows (full text included for context): This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. This approach provides immediate compatibility with existing protocol stacks, while also requiring improvements to make the port easier to use. 2) Assumption that implementers can configure host firewalls Section 3.1 says: > Implementers should be > aware of this possibility and configure the host firewall > appropriately. In reality, there are various host firewall vendors (McAfee, Kaspersky, Norton, etc.) One cannot simply assume that the implementer of an arbitrary application can write code to configure all host firewalls that might be installed on the machine that an end-user or admin will install the application on. [Karstens] The document’s use of “implementer” here is poor terminology. Using RFC 7288 terminology, this configuration could be the responsibility of the app developer, network admin, or host admin. There’s also a type of firewall rule that we touched on earlier in the conversation and seems to play a significant role in modern host firewalls, which are rules based on the application instead of traffic patterns. It appears that many host firewalls try to make configuring application rules as easy as possible by prompting the user in real time via a pop-up dialog. Some examples: · Windows Defender Firewall has the “Windows Security Alert” dialog that informs the user that “Windows Defender Firewall has blocked some features of this app” and allows the user to configure access. · Norton Smart Firewall includes Program Rules and notifies the user with a firewall alert when a program attempts to access the network (see https://support.norton.com/sp/en/us/home/current/solutions/v20240108181430529) · McAfee’s Advanced Firewall appears to work with Windows Defender Firewall and blocks outgoing connections (see https://www.mcafee.com/support/s/article/000002150?language=en_US) · ZoneAlarm has Application Control alerts (see https://support.zonealarm.com/hc/en-us/articles/360060709831-Managing-Basic-Application-Control-Settings) · Comodo Internet Security has Security Alerts (see https://help.comodo.com/topic-72-1-451-4706-.html) Section 1 does have an out: > Use of this port is optional because there may be circumstances where > assigning a port is preferred, such as when participants cannot meet > the requirements in Section 3 and Section 4. I think section 3.1 should instead say that in general, applications that need a pattern like the one in 3.1 should continue to request their own port and not use the Multicast Application Port. That's already consistent with section 1, and avoids implying something that ignores reality. If we add port numbers to the exchange in section 3.1 (using “50000” and “60000” as a stand-in for a dynamic port), then we get the following: 1. (Multicast) Host A to group containing Host B S: 50000 D: 8738 2. (Unicast) Host B to Host A S: 60000 D: 50000 3. (Unicast) Host A to Host B S: 50000 D: 60000 It seems like a firewall rule could be written to characterize this traffic pattern: 1. Host A observes multicast using D=8738 and for an approved multicast address. It notes source port 50000 and looks for replies using that port. 2. Host A receives Message 2 and notes that its destination is 50000, the port recorded in Message 1. It allows the traffic through and notes source port 60000. 3. Host A observes unicast using the source port recorded in Message 1 and the destination port recorded in Message 2. In the absence of such a rule, or the ability of the host firewall to allow traffic for a given application (per the user configuration described above), then I would agree that requesting a port is the only alternative. 3) Reference to RFC 7288 I'll also repeat my earlier recommendation to add an informative reference to RFC 7288 in the text on host firewall considerations. For example... OLD: Certain host firewalls are designed to accept incoming messages as OLD: long as there was first an outgoing message using the same set of OLD: ports. Consider the following sequence of messages: NEW: Certain host firewalls are designed to accept incoming messages as NEW: long as there was first an outgoing message using the same set of NEW: ports. (See [RFC7288] for more discussion.) Consider the following sequence of messages: [Karstens] Adding the reference here is fine with me. Can we narrow it down to a specific section of RFC 7288? 4) Application Requirements Section 4 says: > Applications running on a non-conformant host SHALL discard all > datagrams that do not have the multicast address used by the > application. Above is too broadly stated. In think you specifically mean datagrams received on the Multicast Application Port. As worded, it says that the application cannot have other sockets listening on other ports and accept packets on them. [Karstens] Good catch, I will fix this. 5) Security Considerations There's another security consideration missing. Applications that don't use the Multicast Application Port can often rely on host firewall behavior (which may be the default on host platforms the application is installable on) to prevent unsolicited inbound traffic and hence help mitigate some classes of attack. By using the Multicast Application Port, that external protection no longer exists, so the application must be prepared to deal with any resulting security concerns itself. That includes address/port scans, and attacks against the application itself. (Again see RFC 7288.) The above needs to be called out in the Security Considerations section. [Karstens] I think this problem is shared with the existing port system as well. The only difference is that making a rule to allow incoming traffic to the Multicast Application Port would allow all applications using the port. If we recommend that firewall rules referencing the Multicast Application Port also consider the multicast address, then we’d get the same protection offered by other rules that just reference the port. Dave > -----Original Message----- > From: Wassim Haddad via Datatracker > <[email protected]<mailto:[email protected]>> > Sent: Monday, January 26, 2026 9:15 AM > To: > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; intarea- > [email protected]<mailto:[email protected]> > Subject: [Int-area] WG Last Call: > draft-ietf-intarea-multicast-application-port-03 > (Ends 2026-02-09) > > Dear colleagues, > > This message starts a WG Last Call for: > draft-ietf-intarea-multicast-application-port-03 > > This Working Group Last Call ends on 2026-02-09 > > Please note we need at least 5 reviews to progress the draft to next step. > > Abstract: > This document discusses the drawbacks of the current practice of > assigning a UDP port to each multicast application. Such assignments > are redundant because the multicast address already uniquely > identifies the data. The document proposes assigning a UDP port > specifically for use with multicast applications and lists > requirements for using this port. This method does not require > modification to existing protocol stacks, though recommended updates > to make the port easier to use are included. > > File can be retrieved from: > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected]<mailto:[email protected]> in > copy. Objections should be explained and suggestions to resolve them are > highly > appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property > Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the provisions > of > BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at > [3]. > > Thank you. > > [1] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wBMmNVyrw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/bcp78/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wBMmNVyrw$> > [2] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAcx8g8TQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/bcp79/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAcx8g8TQ$> > [3] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAu2iQWow$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc6701/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAu2iQWow$> > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-intarea-multicast-application-port/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAIIhZxCw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-intarea-multicast-application-port/__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAIIhZxCw$> > > There is also an HTMLized version available at: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-intarea-multicast-application-port-03__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wDNPBIPDg$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-intarea-multicast-application-port-03__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wDNPBIPDg$> > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-intarea-multicast-application-port-__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAFQLDkZQ$<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-ietf-intarea-multicast-application-port-__;!!EJc4YC3iFmQ!RgVRKPn4wFOvXHzhNonMiEmjUeybwQrEmQc__RfeYEaqVlwMVWCKzviR9TQt1kCHSdUljuXQsYLsBwxfYSlKObjs6wAFQLDkZQ$> > 03 > > _______________________________________________ > Int-area mailing list -- [email protected]<mailto:[email protected]> To > unsubscribe send an email to int-area- > [email protected]<mailto:[email protected]> _______________________________________________ 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]
