<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 29, 2018 at 11:15 AM Achim Gratz via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, there is still value in the knowledge of which interface the<br>
packet came in so that ntpd can place different levels of trust<br>
depending on whether it's from a private (virtual) network segement, an<br>
internal or public network.  Also, this information would potentially be<br>
quite valuable to get a better grip on asymmetric network delays, which<br>
are dominating the residual timing error on many types of networks these<br>
days.<br>
<br>
Of course this can be done in various ways, among them tagging the<br>
packets, running multiple threads or even a fleet of DJB style mini<br>
daemons.<br></blockquote><div><br></div><div>That would be an interesting and potentially useful feature.  But probably better done with a from scratch implementation, instead of hammering the existing userspace packet filter to do it.</div><div><br></div><div>(My own inclination is to do it with explicit and implicit flow tags, but that is a dicussion to have in a year or two.)</div><div><br></div><div>..m</div><div> </div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Mark Atwood<br>
<a href="http://about.me/markatwood">http://about.me/markatwood</a><br>
+1-206-604-2198</p>
</div></div>