[Int-area] Re: WG Last Call: draft-ietf-intarea-multicast-application-port-03 (Ends 2026-02-09)

[Dave Thaler <[e-mail]>]

Just got back from vacation so going through this now…

 

1)      Contradiction in node requirements
 
Draft -03 abstract was:

*  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.

 
You said:
*  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.

 

Draft -04 instead has:

*	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.
*	This approach provides immediate compatibility with existing protocol stacks, while also requiring
*	improvements to make the port easier to use.

 

The green and yellow sentences are contradictory in my reading (“recommended” per green, “requiring” per yellow),

so draft -04 is still problematic I think.

 

2.	Host Firewall Considerations in section 3.1

 

Draft -04 says

*	Host firewalls SHOULD be designed to allow this sequence of messages

 

However, I disagree with this SHOULD as it opens up new security issues (as discussed in RFC 7288)
in that it breaks the ability to have a stealth mode which is a core value proposition.  And the security

considerations section does not even discuss this new security regression.  (The new paragraph in
section 5 does not.)

 

Rather than saying we SHOULD have a security regression, I would like this SHOULD to be removed
and instead do what I originally suggested in this thread, i.e., say that applications that need a sequence
like that in 3.1 should continue to request their own port and not use the Multicast Application Port.
That's already consistent with section 1.
 
3)      Reference to RFC 7288
 
Looks good, thanks.
 
4)      Application Requirements
 
Looks good, thanks.
 
5)      Security Considerations
 
The new paragraph is fine but does not address point 2 above.
 
Dave
 

 

From: Karstens, Nate <Nate.Karstens=[e-mail]> 
Sent: Saturday, February 14, 2026 10:11 AM
To: Karstens, Nate <[e-mail]>; Dave Thaler <[e-mail]>; 'Wassim Haddad' <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Int-area] Re: WG Last Call: draft-ietf-intarea-multicast-application-port-03 (Ends 2026-02-09)

 

Dave,

 

We posted a new version to https://datatracker.ietf.org/doc/draft-ietf-intarea-multicast-application-port/, please let us know if that addresses your feedback.

 

Thanks!

 

Nate

 

From: Karstens, Nate <Nate.Karstens=[e-mail] <mailto:Nate.Karstens=[e-mail]> > 
Sent: Thursday, January 29, 2026 13:00
To: Dave Thaler <dthaler1968=[e-mail] <mailto:dthaler1968=[e-mail]> >; 'Wassim Haddad' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: [Int-area] Re: WG Last Call: draft-ietf-intarea-multicast-application-port-03 (Ends 2026-02-09)

 

Dave, Thanks for your feedback, this is really helpful! Please see the replies below… Cheers, Nate From: Dave Thaler <dthaler1968=40googlemail. com@ dmarc. ietf. org> Sent: Monday, January 26, 2026 1: 28 PM To: 'Wassim Haddad' <Wassim. Haddad@ ericsson. com>;

 

Dave,

 

Thanks for your feedback, this is really helpful!

 

Please see the replies below…

 

Cheers,

 

Nate 

 

From: Dave Thaler <dthaler1968=[e-mail] <mailto:dthaler1968=[e-mail]> > 
Sent: Monday, January 26, 2026 1:28 PM
To: 'Wassim Haddad' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
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://urldefense.com/v3/__https:/support.norton.com/sp/en/us/home/current/solutions/v20240108181430529__;!!EJc4YC3iFmQ!QZVkT1k6bj2x7ZS41wQws16fe2o5Hfee0OvBXYIesO_hzaAmFx-M4NiIkWuCoXjVYpCdXKTkVHgdO8_i6SpXBWzcWHD7hynJUQ$> 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://urldefense.com/v3/__https:/www.mcafee.com/support/s/article/000002150?language=en_US__;!!EJc4YC3iFmQ!QZVkT1k6bj2x7ZS41wQws16fe2o5Hfee0OvBXYIesO_hzaAmFx-M4NiIkWuCoXjVYpCdXKTkVHgdO8_i6SpXBWzcWHB-IEtWlw$> https://www.mcafee.com/support/s/article/000002150?language=en_US)
*       ZoneAlarm has Application Control alerts (see  <https://urldefense.com/v3/__https:/support.zonealarm.com/hc/en-us/articles/360060709831-Managing-Basic-Application-Control-Settings__;!!EJc4YC3iFmQ!QZVkT1k6bj2x7ZS41wQws16fe2o5Hfee0OvBXYIesO_hzaAmFx-M4NiIkWuCoXjVYpCdXKTkVHgdO8_i6SpXBWzcWHBGm1PSnA$> https://support.zonealarm.com/hc/en-us/articles/360060709831-Managing-Basic-Application-Control-Settings)
*       Comodo Internet Security has Security Alerts (see  <https://urldefense.com/v3/__https:/help.comodo.com/topic-72-1-451-4706-.html__;!!EJc4YC3iFmQ!QZVkT1k6bj2x7ZS41wQws16fe2o5Hfee0OvBXYIesO_hzaAmFx-M4NiIkWuCoXjVYpCdXKTkVHgdO8_i6SpXBWzcWHAsNe9kJA$> 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 < <mailto:[e-mail]> [e-mail]>
> Sent: Monday, January 26, 2026 9:15 AM
> To:  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail]; intarea-
>  <mailto:[e-mail]> [e-mail]
> 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  <mailto:[e-mail]> [e-mail] 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 --  <mailto:[e-mail]> [e-mail] To unsubscribe send an email to int-area-
>  <mailto:[e-mail]> [e-mail]
 
_______________________________________________
Int-area mailing list --  <mailto:[e-mail]> [e-mail]
To unsubscribe send an email to  <mailto:[e-mail]> [e-mail]

 

  _____  


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.

 

  _____  


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.