[Int-dir] Re: [Int-area] draft-ietf-intarea-multicast-application-port-04 early Intdir review

[Brian Haberman <[e-mail]>]

Hey Nate,
     One more concern after reading -05. I may have missed discussion of this. If so, just point me to the thread.

Section 2 says:

...the Multicast Application Port SHALL NOT be used as either a source port or destination port for any non-multicast messages.

But, then it says:

If any application messages are unicast, then a different port SHOULD be used for the source port.

Under what kind of conditions can an application violate the SHOULD? And giving them that wiggle room appears to violate the SHALL NOT earlier in the section. Seems to me the SHOULD needs to be a SHALL.

Regards,
Brian

> On May 13, 2026, at 12:17 AM, Karstens, Nate <[e-mail]> wrote:
> 
> Thanks, Brian! We posted draft-ietf-intarea-multicast-application-port-05 to address your comments:
>  
>     • The text in the abstract has been updated
>     • Several changes were made to address Dave’s concerns – details are available in my recent reply to him (also available at https://mailarchive.ietf.org/arch/msg/int-area/QnHMAi7qgK7GPbA-ASMMKNkQQKk/)
>  Please let us know if you have any additional feedback!
>  Cheers,
>  Nate
>  From: Brian Haberman via Datatracker <[e-mail]>
> Sent: Tuesday, February 24, 2026 09:19
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [Int-area] draft-ietf-intarea-multicast-application-port-04 early Intdir review
>  Document: draft-ietf-intarea-multicast-application-port Title: The Multicast Application Port Reviewer: Brian Haberman Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-intarea-multicast-application-port. Document: draft-ietf-intarea-multicast-application-port
> Title: The Multicast Application Port
> Reviewer: Brian Haberman
> Review result: Ready with Issues
>  
> 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://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!EJc4YC3iFmQ!RzZvz9oFHUM_JIyaASAL8_TVGNs5mjnWfnOWMO5i3YlCwHIZktQtLSZYALABEVhtwNsFX54xLw3TDeji-w$
>  
> 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.
>  
>  
> _______________________________________________
> Int-area mailing list -- [e-mail]
> To unsubscribe send an email to [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.