| Newsgroups |
gmane.ietf.dhc |
| Message-ID |
<[email protected]> |
Michael,
Thats an important distinction that I should have thought about before replying. I was thinking client - server but really its client - relay and relay - server in 99% of cases…. It also negates my comparison to Cache-poisoning issue. I need a nap apparently. So if we are only making recommendations for client source port to be locked down, I have zero argument with that. Once we get into relay->Server then we have to consider those packets could be going anywhere.
Rob
Robert Nagy
- - - - - - - - - -
Senior Dive Master | Deep Dive Networking Inc
p: 408.480.5133
e: [email protected]
www.deepdivenetworking.com
> On Feb 29, 2024, at 5:03 PM, Michael Richardson <[email protected]> wrote:
>
>
> [email protected] <[email protected]> wrote:
>> David, I can see that argument. But we also didn't think randomized
>> source ports were going to be important for DNS... I guess I don't see
>> why we should be declaring what an implementer does on the source port
>
> We expect DNS messages to leave the "enterprise" (site) and get returned to
> us. We require it for DNS to work. It's the whole point.
> Yes, there was a point in the past where many DNS requests were *from* port-53.
>
> DHCPv6: not so. Just the opposite.
> OpenWRT actually blocks port 546/547 from being accepted on the wan
> interface, unless it's LL. (zone_wan_input)
> If DHCPv6 leaves the local link, it's because there is a DHCP relay configured.
>
> So I feel confident that we will NEVER need clients to port randomized
> source ports. We *might* decide that there is some scenario where we want a
> DHCPv6 *RELAY* to do something like that, but I'll bet we won't do that
> without a DTLS or IPsec wrapper.
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg