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.