Dave, I posted a new version of the document:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-intarea-multicast-application-port-01&url2=draft-ietf-intarea-multicast-application-port-03&difftype=--html Can you please take a look and let me know if this satisfies your concerns? Thanks, Nate From: Karstens, Nate <[email protected]> Sent: Friday, November 7, 2025 01:08 To: Dave Thaler <[email protected]>; 'Dave Thaler' <[email protected]>; [email protected] Cc: 'Internet Area' <[email protected]> Subject: [Int-area] Re: draft-ietf-intarea-multicast-application-port-01 interaction with host firewalls Dave, I think your suggestion about not using 8738 as the destination for any unicast traffic is reasonable. The last two paragraphs of the host requirements section states this already: Hosts SHALL prevent applications from sending non-multicast Dave, I think your suggestion about not using 8738 as the destination for any unicast traffic is reasonable. The last two paragraphs of the host requirements section states this already: Hosts SHALL prevent applications from sending non-multicast packets to this destination port by having the send operation return an error code. Hosts SHALL discard all incoming, non-multicast packets that use this destination port. We recognize that hosts may not implement the requirements in section three, so clarifying use of the port in section 2 would make sense. Here is what I would propose: The _requested_ port SHALL NOT be used as a destination port for any non-multicast traffic. It MAY be used as a source port by an application that uses exclusively multicast messages. Regarding firewalls, I don’t think the user configuration referred to ports, it was more of a general permission for the application to access the network. (The user could probably find port information in an advanced window). I didn’t know that some could be configured by applications during installation, which is a nice feature. In any case, I think your suggestion to include information about host firewalls will be helpful for the reader. Thanks for talking that through! I’ll get a new version out for review as soon as possible. Nate From: Dave Thaler <[email protected]<mailto:[email protected]>> Sent: Thursday, November 6, 2025 09:29 To: Karstens, Nate <[email protected]<mailto:[email protected]>>; 'Dave Thaler' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: 'Internet Area' <[email protected]<mailto:[email protected]>> Subject: RE: [Int-area] draft-ietf-intarea-multicast-application-port-01 interaction with host firewalls Thanks for the thoughtful reply. Nate Karstens wrote: > We discussed this in the meeting briefly, but just to make sure it’s covered, > the reason that Reply Option 1 is prohibited by section 2 is that if multiple > applications were Thanks for the thoughtful reply. Nate Karstens wrote: > We discussed this in the meeting briefly, but just to make sure it’s covered, > the reason that Reply Option 1 is prohibited by section 2 is that if multiple > applications were using port 8738, then any unicast reply would be distributed > to applications using a round-robin mechanism (at least in Linux). > Here’s the exchange for this: > > Request: > Source: 10.1.1.1:1234 (not using 8738 because the application also sends > unicast messages, per sec 2 para 2) > Dest: 224.1.1.1:8738 > > Reply option 1: > Source: 10.2.2.2:8738 (this violates the current wording of section 2, so > the current draft disallows this) > Dest: 10.1.1.1:1234 In the common exchange above there is never a unicast message destined to 8738 so the issue you are worried about would not occur. That suggests an alternate wording of section 2, which is about: not using 8738 as a source port _if the application can receive unicast_. Or even better, just say that 8738 MUST NOT be used as a _destination_ port for any unicast traffic. That would permit Reply option 1 and still prevent the situation you mention. > Reply to Reply option 1: > Source: 10.1.1.1:1234 > Dest: 10.2.2.2:8738 <== Which application gets it? My suggestion above would disallow the above Reply to Reply option 1 while permitting Reply option 1. > Returning now to the firewall discussion, if I’m remembering correctly > about how some of these host firewalls work, the user can configure > the firewall to support any traffic for designated applications. > Some of them require the user to proactively add applications to the > approved list, while others will prompt the user to do this. Most of the time, users don't configure host firewalls, application installer programs do. Host firewalls are most commonly used by users who have no clue about firewall details or what a "port" is. > Would one solution to this be that the user should configure the host > firewall appropriately? If so, it seems like it covers both the first (Request > and Reply Option 2) and second (Reply Option 2 only) scenarios. In my opinion no (for reasons above), hence my suggestion above. > If the user does not configure their firewall correctly, then both of these > scenarios will fail. The second scenario isn’t relevant to the I-D, but it is > a valid scenario that host firewalls would want to support. Assuming by "the second scenario" you mean "Reply to Reply option 1", host firewalls already permit that, since the Reply to Reply is solicited (by the Reply option 1) so requires no configuration. > Furthermore, it is useful to see that both scenarios are failing in the > same way – that is, the proposal in the I-D isn’t any worse. I didn't follow this. > Another solution might be that firewalls should automatically allow the > Request / Reply Option 2 scenario by allowing incoming replies directed > to the source address/port of the Request. I think the draft's recommendations/requirements for apps need to deal with what to do in the presence of _existing_ (unmodified) firewall deployments just like it has text now about existing OS's. At most, you can make statements about what the app's installer program should do, but generally the app installer program won't be aware of all possible host firewalls... it might be aware of one that comes with the OS (like a Windows host firewall) but less likely a third-party one like Norton, McAfee, etc. > Request: > Source: 10.1.1.1:1234 (not using 8738 because the application also sends > unicast messages, per sec 2 para 2) > Dest: 224.1.1.1:8738 > > Reply option 2: > Source: 10.2.2.2:5678 (using a separate socket per sec 2 para 3) > Dest: 10.1.1.1:1234 This is indistinguishable from an attack/probe, which is what the firewall is designed to prevent. See section 5 of RFC 7288. > However, I’m not sure this is a good idea as it would be a great protocol to > attack the host with: 1) Request message multicasts availability of a command > & control server running on the host and punches a hole through the firewall > and 2) Reply message from attacker goes through firewall and begins C&C > session. Exactly, which is why there's zero chance a host firewall would accept it by default. > So, it seems like the best solution would be to have the user manually > configure > the firewall to support the application, which I believe is what they would > have to > do now anyway. Disagree (see above). > Does that make sense to you? If so, what do you think? > > Thanks! > > Nate Dave ________________________________ 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.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
