Re: [dhcwg] recommendation on DHCP6 source port numbers

["[e-mail]" <[e-mail]>]

Just my $.02,

In most enterprise implementations I deal with (and these range from a small school to a fortune 50 customer)  DHCP most often does go through one or more firewalls, and worse now it often can go through what cloud providers call firewalls (not all suck but for some…just wow).  So I think factoring in firewalls is critical. I again am for the locked source/destination, yet my argument is “is it our role to tell them which source port?" We certainly say which destination/listening port. But should we do any more than a recommendation on source or a tidbit on why using matching source-destination is helpful for firewalls and say monitoring/security tools?  To me Destination = MUST, Source = SHOULD (and like a weak should)

Rob


> On Feb 29, 2024, at 12:23 PM, Ted Lemon <[e-mail]> wrote:
> 
> Not going through firewalls definitely seems like a feature to me. If it's intended to go through the firewall, requiring the admin to explicitly configure that makes a lot of sense.
> 
> On Thu, Feb 29, 2024 at 3:12 PM Bernie Volz <[e-mail] <mailto:[e-mail]>> wrote:
>> We’re not starting from scratch - thus if you mandate this, you make existing implementations that are operating non-compliant. And if it cannot be mandated, you cannot rely on it.
>> 
>> Also, dhcp is probably not a protocol that goes through firewalls? Firewalls likely block these ports.
>> 
>> - Bernie (from iPhone)
>> 
>>> On Feb 29, 2024, at 2:03 PM, David Farmer <farmer=[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> Actually, given that return DHCP messages MUST be sent to their designated destination ports and not the source port used by the originating DHCP message, there is no advantage to using randomized source ports to prevent spoofing. Using randomized source ports only makes firewall traversal for DHCP messages more difficult.
>>> 
>>> Thanks.
>>> 
>>> On Thu, Feb 29, 2024 at 12:44 PM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
>>>> I think we are in the middle of the (no end in sight argument) of;  If we make it completely predictable it is easy to monitor and punch holes for firewalls vs if we make it easily predictable it is super easy to exploit. Just look at DNS needing to randomize source ports to combat cache poisoning. I think we don't have to say it “Should" be source and destination port that is  forced. People can do that if they choose to given the current text, but we don't paint them into a corner.
>>>> 
>>>> Rob
>>>> 
>>>> 
>>>> 
>>>>> On Feb 29, 2024, at 10:39 AM, David Farmer <farmer=[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> If we did, that would ensure DHCP messages will make it through typical stateful firewalls without special rules.
>>>>> 
>>>>>> Clients receive DHCP messages on UDP (destination) port 546.  Servers and relay agents receive DHCP messages on UDP (destination) port 547.
>>>>>> 
>>>>>> Clients, servers, and relay agents SHOULD send DHCP messages from their designated destination ports, as this will facilitate firewall traversal for DHCP messages. Nevertheless, DHCP messages MUST be accepted from any UDP (source) port, and regardless of the source port used, return DHCP messages MUST be sent to their designated destination port.
>>>>> 
>>>>> On Thu, Feb 29, 2024 at 12:05 PM Ole Trøan <otroan=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Should we also make it recommended to use the designated port as the source port? With the may to send arbitrary port and a must to accept an arbitrary port?
>>>>>> 
>>>>>> O. 
>>>>>> 
>>>>>>> On 29 Feb 2024, at 18:51, David Farmer <farmer=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Ok, it's a little less wordy this time.
>>>>>>> 
>>>>>>> Clients receive DHCP messages on UDP (destination) port 546.  Servers and relay agents receive DHCP messages on UDP (destination) port 547.
>>>>>>> 
>>>>>>> Clients, servers, and relay agents MAY send DHCP messages from any UDP (source) port they are allowed to use, including their designated destination ports. Nevertheless, regardless of the source port used, DHCP messages MUST be sent to their designated destination ports.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> On Thu, Feb 29, 2024 at 10:24 AM David Farmer <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> Would this text clarify things?
>>>>>>>> 
>>>>>>>> Clients receive DHCP messages on UDP (destination) port 546.  Servers and relay agents receive DHCP messages on UDP (destination) port 547.
>>>>>>>> 
>>>>>>>> Clients, servers, and relay agents MAY send DHCP messages from any UDP (source) port they are allowed to use, including their designated destination ports. Nevertheless, regardless of the source port the client uses, the server or relay agent MUST send traffic to the designated destination port of the client. And vice versa, regardless of the source port used by the server or relay agent, the client MUST send traffic to the designated destination port of the server or relay agent.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>> On Thu, Feb 29, 2024 at 10:03 AM Ole Troan <otroan=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> Bernie,
>>>>>>>>> 
>>>>>>>>> > DHCPv6 has been successfully deployed and this is the first I recall of this kind of discussion/issue.
>>>>>>>>> > You would likely also invalidate a lot of implementations with such a change, which is not really in line with advancing this to Full Standard.
>>>>>>>>> 
>>>>>>>>> It’s a lot more important to have the specification clear and unambiguous. I think it has been shown that it isn’t.
>>>>>>>>> Happy with whatever solution there is consensus for, but the ambiguity has to be resolved I think.
>>>>>>>>> 
>>>>>>>>> O.
>>>>>>>>> _______________________________________________
>>>>>>>>> dhcwg mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> ===============================================
>>>>>>>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>>>>>>>> Networking & Telecommunication Services
>>>>>>>> Office of Information Technology
>>>>>>>> University of Minnesota   
>>>>>>>> 2218 University Ave SE        Phone: [phone]
>>>>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>>>>> =============================================== 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> ===============================================
>>>>>>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>>>>>>> Networking & Telecommunication Services
>>>>>>> Office of Information Technology
>>>>>>> University of Minnesota   
>>>>>>> 2218 University Ave SE        Phone: [phone]
>>>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>>>> =============================================== 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> ===============================================
>>>>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>>>>> Networking & Telecommunication Services
>>>>> Office of Information Technology
>>>>> University of Minnesota   
>>>>> 2218 University Ave SE        Phone: [phone]
>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>> =============================================== 
>>>>> _______________________________________________
>>>>> dhcwg mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>> 
>>> 
>>> 
>>> -- 
>>> ===============================================
>>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota   
>>> 2218 University Ave SE        Phone: [phone]
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg