Thanks, Jared Somehow everybody tries to escape answering the question asked by giving their correct but orthogonal pet problem space answer. Ted correctly claims the protocols suck security wise, and you correctly claim that there are a lot more deployment considerations in face of risky underlays.
At this point in time i am just trying to get an RFC out the door, and Bens security review was asking for options how to operationalize the choosen protocol to be hardened. My answer was the heuristic. If the anwer of the experts is "do not harden implementations of existing protocols", but only improve protocols or eliminate security risks from underlays, i think that is not a good strategy to show to implementors trying to understand how to best harden existing protocols, but i will happily take that guidance and remove the text about the suggested heuristics. Cheers Toerless On Mon, Oct 26, 2020 at 01:11:33PM -0400, Jared Mauch wrote: > > > > On Oct 26, 2020, at 1:05 PM, Ted Lemon <mel...@fugue.com> wrote: > > > > On Oct 26, 2020, at 12:59 PM, Toerless Eckert <t...@cs.fau.de> wrote: > >> The networks where i am worried are not home networks, > >> but something like an office park network, where supposedly each > >> tenant (company) should have gotten their disjoint L2 domains, ... and then > >> they didn't. And one of the tenants has a "funny" network engineer/hacker. > > > > That???s pretty clearly the thing to fix. > > > > There???s plenty of bad engineering out there, but when on a shared lan > without client isolation enabled (Eg: wireless) many bad things can be done. > > I think explaining that the threat domain is the layer-2 and that > administrators should consider what services are available, eg: do you accept > dhcp server on the network, what devices are permitted to send RA???s etc all > become part of the question.. > > Much of this is just operational guidance in how to run a good network which > prevents these types of bad behaviors and consequences from exceeding their > blast radius. > > - Jared -- --- t...@cs.fau.de _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
