<p dir="ltr"></p>
<p dir="ltr">On Sep 29, 2016 8:22 PM, "Eric S. Raymond" <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br>
><br>
> Gary E. Miller <<a href="mailto:gem@rellim.com">gem@rellim.com</a>>:<br>
> > > But we have one mission imperative that trumps drop-in replacement:<br>
> > > security.  And what makes these modes targets for removal is that,<br>
> > > according to Daniel, there are fundamentally impossible to secure.<br>
> ><br>
> > I would split that hair.  Maybe ntpd could still send broadcast, there<br>
> > are a lot of legacy clients that can not be updated.  But not<br>
> > accept broadcast in.<br>
><br>
> That is an interesting idea!<br>
><br>
> > I not exactly sure what modes you are dropping, but dropping 'peer'<br>
> > mode would be a serious PITA for the isntalled base.  Trying to<br>
> > update an old router, without a support contract, is pretty much<br>
> > impossible.  At least not without some license or legal violation.<br>
><br>
> Ordinary peer mode is unicast, yes?  No way we'd ever drop that.</p>
<p dir="ltr">Peer mode is a synonym for symmetric mode which we discussed on the phone earlier today. It has some security problems and no good justification for existing, and when we discussed it at IETF 96 nobody knew of any users. My NTS proposal will be able to solve the security issues. In contrast, I don't currently have any solution for securing broadcast clients.<br>
</p>