Subject: Re: quibbles about what is anycast.

From: Brad Knowles <[email-masked]>
Date: Tue, 5 Nov 2002 06:21:50 -0600

At 2:35 AM -0800 2002/11/05, Bill Woodcock wrote:

>        Brad Knowles wrote faster than he thought:
>      > True anycast for protocols other than UDP?  I sincerely doubt it.
>      > If you have evidence for this, I'd love to see it.
>
>  Works fine for TCP and ICMP.  What protocols do you have doubts about?

	I have doubts about TCP.  Can you explain in more detail how it 
works for TCP, especially for the case where the route from IP 
address A to IP address B changes to a different machine that serves 
IP address B, while in the middle of a connection?  And how often do 
route changes occur?

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 5 Nov 2002 14:50:44 +0100 (CET)

On Tue, 5 Nov 2002, Brad Knowles wrote:

> IP address B, while in the middle of a connection?

If the route changes in the middle of a connection, then the TCP stream is
reset as the new back-end server has no knowledge of the ongoing TCP
stream.  This of course excludes smart backends which pass knowledge of
TCP state around and can continue with the end-user being none-the-wiser.

However, we're discussing TCP as used in DNS.  That means either very
short TCP streams (simply because it was larger than UDP), or mildly long
(AXFRs).

Statistically (and I have pretty graphs to back this up), short-lived TCP
queries are not interrupted due to changes in the underlying routing
infrastructure.

Long-lived TCP streams are an altogether seperate matter, and are more
likely to be interrupted by such changes over a larger path, however this
probability is still low.

> And how often do

In terms of your average DNS TCP connection, hardly ever.

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B             Operations/Security

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Nov 2002 07:54:47 -0800

> I have doubts about TCP.  Can you explain in more detail how it works for
> TCP, especially for the case where the route from IP address A to IP
> address B changes to a different machine that serves IP address B, while
> in the middle of a connection?  And how often do route changes occur?

in actual use, we have been surprised at how well anycast tcp works
within a large isp.  like O(10^5) users for multiple hours.  most routing
instability has a relatively small number of real causes.

randy

---

From: bert hubert <[email-masked]>
Date: Tue, 5 Nov 2002 17:22:09 +0100

> instability has a relatively small number of real causes.

Until you get to the point where a router routes based on, say, the length
of the packet and sends the SYN packet to the left and later packets to the
right. 

Depending on hoping that all your packets will end up in the same place
makes about as much sense as depending on your packets arriving in the same
order as you passed them to the kernel - very little.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Nov 2002 18:20:13 -0800

> order as you passed them to the kernel - very little.

as you seem to have missed the first clause, i will repeat it for you

   IN ACTUAL USE

randy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 8 Nov 2002 15:02:21 +0100

On Tue, Nov 05, 2002 at 02:50:44PM +0100,
 Bruce Campbell <[email-masked]> wrote 

> queries are not interrupted due to changes in the underlying routing

RFC 3258 gave another reason why anycast will work for a set of name
servers widely spreaded (such as in Karrenberg's proposal to anycast
k.root-servers.net):

The second is that the aim of this proposal is to diversify
topological placement; for most users, this means that the
coordination of placement will ensure that new instances of a name
server will be at a significantly different cost metric from existing
instances.  Some set of users may end up in the middle, but that
should be relatively rare.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Nov 2002 11:38:25 +0100

At 15:02 08/11/02, Stephane Bortzmeyer wrote:
>k.root-servers.net): The second is that the aim of this proposal is to 
>diversify

This only addresses the DDoS aspect. Shoul not a global security and
stability vision be considered? What are the cons/pros IRT other threats?
To well disseminate a wrong root information is to make sure that
wrong information will be inoculated faster, better, all over. Will such
a multicasted system be easily restored? Let imagine a root hacking
followed by a DDoS to impeach the further root file correction to raeach
one network area. Is that a stupid scenario?
jfc

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Nov 2002 01:59:15 +0859 ()

jfc;

> wrong information will be inoculated faster, better, all over.

Such attack is more serious with a unicast root server, the single
point of compromise. The wrong information is used immediately all
over the world.

> Will such
> a multicasted system be easily restored?

Yes.

> Let imagine a root hacking

DDoS is a good way to give alert to administrators.

							Masataka Ohta