Early Review of draft-ietf-intarea-multicast-application-port-04
review-ietf-intarea-multicast-application-port-04-intdir-early-haberman-2026-02-24-00

I am an assigned INT directorate reviewer for
draft-ietf-intarea-multicast-application-port. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/

In general, this is a well-written document. I have two concerns and they have
both already been raised on the list (one resolved and the other still under
discussion).

1. Abstract - I flagged the apparent inconsistency with the use of both
"recommended" and "requiring" in the last two sentences. It appears from the
list archive that the authors are fixing that text after Dave Thaler flagged it.

2. Section 3.1 - I agree with Dave Thaler's suggestions around this text
relaxing the stealth mode model described in Section 5 of RFC 7288. The model
illustrated of allowing a communicating peer to reach through the firewall
because it received a datagram with the reserved port opens up a large attack
surface area. For completeness, here is the complete exchange that was posted
to the list by the authors:

1) Current method (requesting a port):
a. (Multicast) Host A to group (source & dest port 9132, currently unassigned)
b. (Unicast) Host B to Host A (source & dest port 9132)
c. (Unicast) Host A to Host B (source & dest port 9132)

2)        From the document:
a.  (Multicast) Host A to group (source port: 50000, dest port: 8738)
b.  (Unicast) Host B to Host A (source port: 60000, dest port: 50000)
c.  (Unicast) Host A to Host B (source port: 50000, dest port: 60000)

Both methods require the firewall to have generalized behavior that correlates
port information associated with multicast traffic to be applicable to incoming
unicast traffic. Does that behavior require the firewall to allow the incoming
unicast traffic to be carried over any transport protocol? Or just the
transport protocol used for the outgoing multicast traffic?

Assuming there is sufficient functionality to correlate inbound unicast traffic
with outbound multicast rules, the proposed change opens a large attack
surface. In the current method, an application is indicating to the firewall
that it is willing to accept traffic when s_port = d_port = 9132. That means
the firewall can drop any inbound traffic with s_port != 9132. And, as was
pointed out, this creates a single firewall rule (accept all 9132/9132). In the
proposed change, an attacker can potentially overwhelm the firewall by
constantly rotating the s_port, creating new entries in the firewall for every
s_port/9132 combination seen.

In my opinion, a host that wants to support such multicast/unicast traffic
mixing would want to do so with simpler rules. That would put them in the
category of current behavior and requesting a dedicated port.

If the WG consensus is to keep the existing 3.1, the security considerations
section needs to include discussion of the threat described above.