Re: DNS hardening, was Re: Dan Kaminsky

[Christopher Morrow <morrowc.lists () gmail com>]

On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixie<vixie () isc org> wrote:
> note, i went off-topic in my previous note, and i'll be answering florian
> on namedroppers@ since it's not operational.  chris's note was operational:
>
> > Date: Thu, 6 Aug 2009 10:18:11 -0400
> > From: Christopher Morrow <morrowc.lists () gmail com>
> >
> > awesome, how does that work with devices in the f-root-anycast design?
> > (both local hosts in the rack and if I flip from rack to rack) If I send
> > along a request to a host which I do not have an association created do I
> > get a failure and then re-setup? (inducing further latency)
>
> yes.  so, association setup cost will occur once per route-change event.
> note that the f-root-anycast design already hashes by flow within a rack

pulling something I didn't previously understand from an ongoing
discussion on the LISP/v6ops mailing lists... most routers today only
hash on tcp/udp so.. sctp isn't going to hash in the same
'deterministic' manner, or someone should probably test that that is
the case.

> to keep TCP from failing, so the only route-change events of interest to
> this point are in wide area BGP.

right, and the (I think K-root) K-root folks had a study showing <1%
of sessions seemed to be failing in this manner? (nanog in Toronto I
think?)

> > ...: "Do loadbalancers, or loadbalanced deployments, deal with this
> > properly?" (loadbalancers like F5, citrix, radware, cisco, etc...)
>
> as far as i know, no loadbalancer understands SCTP today.  if they can be
> made to pass SCTP through unmodified and only do their enhanced L4 on UDP
> and TCP as they do now, all will be well.  if not then a loadbalancer
> upgrade or removal will be nec'y for anyone who wants to deploy SCTP.
>
> it's interesting to me that existing deployments of L4-aware packet level
> devices can form a barrier to new kinds of L4.  it's as if the internet is
> really just the web, and our networks are TCP/UDP networks not IP networks.

sadly, people have (and continue) to make simplifying assumptions
while designing/deploying equipment.

-Chris