Subject: Re: DoS and anycast

From: Bill Woodcock <[email-masked]>
Date: Tue, 29 Oct 2002 11:42:19 -0800 (PST)

On Tue, 29 Oct 2002, Bill Manning wrote:
    > anycast will not prevent DoS attacks.

Correct.  It will merely sink attacks at the nearest instance.  This is
not particularly useful until there are a _lot_ of instances.  For
instance, if every major carrier ran instances near their customer edges,
then all attacks would be sunk before they left any of those carriers, or
before they even affected those carrier's internal backbones.  That would
be ideal, since it would localize the pain in the same locality as the
fault.  However, we're presumably quite a long ways away from being there.

                                -Bill

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Ben Stern <[email-masked]>
Date: Fri, 1 Nov 2002 16:19:58 -0500

> fault.  However, we're presumably quite a long ways away from being there.

At risk of wandering far off topic, I suspect that were there some attempt
(admittedly requiring a fair amount of effort and administrivia) to provide
liasons between the RSAAC and the major ISPs, it might be overall fairly
easy to set up extra (anycasted) roots at the major ISPs.

I obviously cannot speak for other major ISPs, and am speaking here as an
individual, not as a representative of AS2548, but I do not see anything
obviously stopping various national carriers from anycasting the root, other
than a) lack of obvious contacts at the roots, and b) lack of perceived
authority. [0] [1]

Feel free to correct me if I am missing something that is preventing major
ISPs from volunteering to anycast the roots today.

Ben Stern
[0] In reference to NOTE WELL et al, this is not in any way a statement of
    the operations at AS2548, or of the policy or opinions of Allegiance
    Internet.
[1] It strikes me as playing dirty pool with the worldwide DNS to anycast
    the root zone without explicit permission from the RSAAC, since although
    the immediate ramifications are only disruptive to customers, doing so
    could lead to a worldwide loss of reputation as "that carrier that stole
    a copy of the root zone."
-- 
Ben Stern             UNIX & Networks Monkey             [email-masked]
 This post doesn't represent AI, even if I claim it does.  Neener neener.
UM Linux Users' Group     Electromagnetic Networks      Microbrew Software
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 3 Nov 2002 00:04:44 -0600

>  than a) lack of obvious contacts at the roots, and b) lack of perceived

	I don't trust them to do the job right.  Even if they should, by 
some miracle, manage to get a suitable copy of the current root zone, 
I wouldn't trust them to be able to properly anycast that to anyone 
else.  I wouldn't trust them to be able to provide that information 
to their own recursive/caching customers.  And once they set that 
stuff up, there'd be no way to get them to stop.

	If you want to go the anycast root route, I think we'd be better 
off selecting a few underperforming root nameservers, and then find 
contacts at the IP address registries (RIPE, APNIC, JPNIC, etc...) 
and see if we can find someone suitable there to provide the proper 
routing and nameservice.  I'd trust them more than I would anyone at 
most major ISPs.  I know a guy at AOL that I'd trust to do the 
nameservice side correctly, but I'm not sure I'd trust the networking 
guys to avoid screwing things up.

	Then there's the issue of current DNS UDP truncation at the 
roots.  There's no way this would fit into ~500 bytes:

% dig @a.root-servers.net. . any +vc

; <<>> DiG 8.3 <<>> @a.root-servers.net. . any +vc
; (1 server found)
;; res options: init usevc recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40904
;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 13, ADDITIONAL: 13
;; QUERY SECTION:
;;      ., type = ANY, class = IN

;; ANSWER SECTION:
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.ROOT-SERVERS.NET.
.                       6D IN NS        C.ROOT-SERVERS.NET.
.                       6D IN NS        G.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.
.                       6D IN NS        B.ROOT-SERVERS.NET.
.                       6D IN NS        J.ROOT-SERVERS.NET.
.                       6D IN NS        K.ROOT-SERVERS.NET.
.                       6D IN NS        L.ROOT-SERVERS.NET.
.                       6D IN NS        M.ROOT-SERVERS.NET.
.                       6D IN NS        I.ROOT-SERVERS.NET.
.                       6D IN NS        E.ROOT-SERVERS.NET.
.                       6D IN NS        D.ROOT-SERVERS.NET.
.                       1D IN SOA       A.ROOT-SERVERS.NET. 
NSTLD.VERISIGN-GRS.COM. (
                                         2002110201      ; serial
                                         30M             ; refresh
                                         15M             ; retry
                                         1W              ; expiry
                                         1D )            ; minimum

;; AUTHORITY SECTION:
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.ROOT-SERVERS.NET.
.                       6D IN NS        C.ROOT-SERVERS.NET.
.                       6D IN NS        G.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.
.                       6D IN NS        B.ROOT-SERVERS.NET.
.                       6D IN NS        J.ROOT-SERVERS.NET.
.                       6D IN NS        K.ROOT-SERVERS.NET.
.                       6D IN NS        L.ROOT-SERVERS.NET.
.                       6D IN NS        M.ROOT-SERVERS.NET.
.                       6D IN NS        I.ROOT-SERVERS.NET.
.                       6D IN NS        E.ROOT-SERVERS.NET.
.                       6D IN NS        D.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
C.ROOT-SERVERS.NET.     5w6d16h IN A    192.33.4.12
G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241
B.ROOT-SERVERS.NET.     5w6d16h IN A    128.9.0.107
J.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.10
K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
E.ROOT-SERVERS.NET.     5w6d16h IN A    192.203.230.10
D.ROOT-SERVERS.NET.     5w6d16h IN A    128.8.10.90

;; Total query time: 236 msec
;; FROM: XXXXXXX to SERVER: a.root-servers.net.  198.41.0.4
;; WHEN: Sun Nov  3 00:03:02 2002
;; MSG SIZE  sent: 17  rcvd: 662

-- 
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: Masataka Ohta <[email-masked]>
Date: Sun, 3 Nov 2002 22:38:07 +0859 ()

Brad;

> 	I don't trust them to do the job right.

That's why every ISP should run anycast root servers by itself
not relying on ones run by adjacent ISPs.

> I know a guy at AOL that I'd trust to do the 

You are saying that, even if you securely retreive some address
from DNS, you do not trust the networking guys connect you to
a host of the address.

Then, there is no point of secure DNS.

> roots.  There's no way this would fit into ~500 bytes:

Sounds like you never took a look at "anycast".

With UDP without truncation, we can run millions of root servers.

							Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Sun, 3 Nov 2002 11:54:54 -0600

>  not relying on ones run by adjacent ISPs.

	No.  Not at all.  That is why *NONE* of them should be doing 
anycast root.  None of them are likely to get it right, and the more 
of them doing it, the more risk there is that it will get screwed up. 
Since they would be advertising this accessibility to anyone who 
accepts their route announcements, they could take down large chunks 
of the 'net.

	Under no circumstances whatsoever should Joe Random ISP be 
running anycast root.

	The only people who should be running anycast root are the people 
we know and trust to do the job right, and where we can be reasonably 
sure that the organization will continue to have the necessary skills 
& talents to do the job if/when that person (or group of people) may 
move on.

	Moreover, these people should be the ones that we actively 
solicit to perform this task.

>  from DNS, you do not trust the networking guys connect you to

	Yup.  Moreover, while I would trust this one guy to do the DNS 
side correctly, I don't know that I'd trust anyone else there to do 
the same.  So, if/when he left, there might not be a good person to 
replace him in this task.

>  Then, there is no point of secure DNS.

	Absolutely not.  I don't know where you get this concept of 
twisting someone's words and then twisting their conclusions to 
support your own half-baked ideas, but you are, yet once again, 
absolutely and completely wrong.

	The point of using a cryptographically secure DNS is that the 
packets could pass through any number of untrusted paths, and the 
data would remain protected.

	At least, we'd be likely to survive any unintentional damage caused.

	If there were an active attack, they might be able to compromise 
your idea of what the keys should be, and do a man-in-the-middle 
attack on all signed data (modifying the data, substituting their 
keys, and then re-signing on the fly), but that would take a fair 
amount of work.

	I imagine the Chinese government could do it, but I don't imagine 
that there are too many other groups out there that could.

>  Sounds like you never took a look at "anycast".

	Anycast requires that the data fit into a single UDP packet, 
which cannot be more than 512 bytes long.  TCP does not anycast. 
Therefore, given that the DNS requires that we re-query with TCP any 
truncated DNS response, we need to eliminate the source of the 
truncation before we can reasonably expect to anycast the UDP.

>  With UDP without truncation, we can run millions of root servers.

	Sure.  But we do have truncation, so we can't do this.  We have 
to eliminate the truncation first.

	Moreover, we wouldn't want to run millions of root servers 
anyway.  There aren't a million people (or a hundred thousand, or ten 
thousand, or a thousand) people on the 'net that I would trust to run 
an anycast root, and there aren't even that many people I'd trust to 
run the network for an anycast root.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 4 Nov 2002 09:49:09 +0859 ()

Brad;

> to eliminate the truncation first.

First, you MUST read the anycast proposal.

Let me know, if you are done.

						Masataka Ohta

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 4 Nov 2002 10:24:59 +0100 (CET)

> 	Under no circumstances whatsoever should Joe Random ISP be

Well, if they do it to their own network, thats their problem.  If they
advertise reachability to it without prior approval, thats everyone's
problem.

> which cannot be more than 512 bytes long.  TCP does not anycast.

*sigh*.  'Anycast' just means that a given route is advertised by multiple
points (could be the same entity, could be different entities).  Your
normal BGP path-selection algorithms choose the 'nearest' server based on
the shortest path that your router sees.

Some pretty graphs showing that anycast works can be found linked from
http://www.as112.net/ , and in particular TCP queries received by the RIPE
NCC's AS112 nameserver can be found at
http://www.ripe.net/as112/xstats_RTCP.html

Regards,

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

---

From: Robert Elz <[email-masked]>
Date: Mon, 04 Nov 2002 18:35:00 +0700

Date:        Mon, 4 Nov 2002 10:24:59 +0100 (CET)
    From:        Bruce Campbell <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well, if they do it to their own network, thats their problem.

It becomes their customers' problem, which I suspect was the point.
Particularly since (other than by RTT measurement, and knowing what
the answer should be) it is very difficult to determine whether or not
your ISP has done this.

  | *sigh*.  'Anycast' just means that a given route is advertised by multiple
  | points (could be the same entity, could be different entities).

If it is the same entity, then that's just IP routing (as it was always
meant to be), and isn't interesting at all.

It is only anycast when there are multiple different entities that can
receive the packet.

That you can't safely make work with TCP (sometimes it might work,
other times not).

Note: that taking over a route to some address, and advertising it as
pointing to some other place, is not anycast.   That's route hijacking.
If all you're doing is forcing all packet from one region of the net to
go to one particular end-point, instead of another, you haven't done
anycast under any reasonable definition of the term.

Anycast means that the packet could do to any of a set of servers, that
you cannot predict in advance (may depend upon which is up at the time,
what routing looks like, ...)

Please everyone stop abusing the "anycast" term to mean other things
than that, and especially stop abusing it to mean "route hijacking,
but we're good guys not doing it for evil purposes".

kre

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 05:33:32 -0800

> Well, if they do it to their own network, thats their problem.
> If they advertise reachability to it without prior approval,
> thats everyone's problem.

bingo!

note that the large isps have been running anycast caches (and some
auths) for many years.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 06:52:41 -0800

> The first sentence which was quoted said Joe Random ISP is to run one 
> of the anycast root servers. What Randy says is that one organization 
> controls all copies of some address which is anycasted.

i certainly did not mean to say that.

to be specific, i see no reason that the root cache ip address for
server X should not be anycast internally within multiple isps as
long as
  o the isps' anycast servers serve consistent data
  o the scope of the anycast routing announcement is bounded
  o if X is controlled by some entity, e.g. the iana, that the
    entity coordinates the mechanism(s) of zone distribution and
    authentication, and maybe even has means of testing content

randy

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Nov 2002 14:53:15 +0100

> note that the large isps have been running anycast caches (and some

I think we are sliding away from the original topic here, or?

For me, that is a very big difference.

I definitely want one and only one organization owning/controlling all 
copies of the same IP-address.

I.e. mapping IP-address:AS-number:Organization is static.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Nov 2002 16:04:56 +0100

>   o the isps' anycast servers serve consistent data

Ack

>   o the scope of the anycast routing announcement is bounded

Ack

>     authentication, and maybe even has means of testing content

I don't know if we say the same thing. Let me try to explain what I 
think:

If organization X is responsible for IP address Y today, i.e. X:Y is in 
the whois database, then X is also the organization people will call 
when wrong data comes from address Y, regardless of what copy of Y the 
wrong data comes from.

Because of this, for every Y, there must be an X which know where all 
copies of Y is, so they can see/detect which one have wrong data -- and 
fix it. The organization X should even have a warning system which 
warns them when one of the copies of Y give wrong data / is out of sync.

    paf

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 07:15:54 -0800

> When _people_ see problems with data from one IP-address, they call 
> whatever party is responsible for that IP address.

no, they call their isp.  the vast majority of them wouldn't know
an ip address if it bit them on the butt.

randy

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Nov 2002 16:12:28 +0100

On måndag, nov 4, 2002, at 16:07 Europe/Stockholm, Randy Bush wrote:

> when users have problems, they call their isp, just as they do now.
> life can be simple.

I explicitly didn't say "users", I said "people".

    paf

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 07:07:52 -0800

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 07:28:00 -0800

> Who do people at the ISP call?

when it is a dns problem, their dns folk.  do remember that this
happens today and has been happening for many years.  isps have 
been using anycast dns for many years.

> Say I buy IP from ISP A, which in turn buy transit from B which
> buys transit from C. If C internally have an anycast copy of IP
> address 1.2.3.4, and I send a packet to that address, will the
> packet go to the copy of the 1.2.3.4 address at ISP C, or to ISP
> D where the "original" is, the one which is mentioned in whois?

first, this is the same problem as any transitive service.

second, as many of us have repeatedly said, routing of anycast
addresses has to be appropriately scoped, as it has to be today.
it would be useful to have a discussion of 'appropriately' if we
could stop ratholing on other issues.

randy

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Nov 2002 16:23:49 +0100

Say I buy IP from ISP A, which in turn buy transit from B which buys 
transit from C. If C internally have an anycast copy of IP address 
1.2.3.4, and I send a packet to that address, will the packet go to the 
copy of the 1.2.3.4 address at ISP C, or to ISP D where the "original" 
is, the one which is mentioned in whois?

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Nov 2002 16:45:35 +0100

On måndag, nov 4, 2002, at 16:28 Europe/Stockholm, Randy Bush wrote:

> when it is a dns problem, their dns folk.

No, not if the DNS problem has to do with problems at a DNS server they 
don't have inside their network.

> do remember that this

Yes, but not for what we are now discussing, if I understand things 
correctly. See my question below.

Also, when you say "isps", you are using a very very very broad brush, 
and that argument doesn't help in this discussion.

> could stop ratholing on other issues.

I thought I had a very specific question?

Default route for ISP A is to B, for B is to C. If C _internally_ have 
a copy of the IP address 1.2.3.4 for it's own use, will traffic from B 
to C reach that server, or the real 1.2.3.4 which is at D which B ask C 
to transit traffic to?

Customer -> A -> B -> C ----> D
                       |       |
                       v       v
                    1.2.3.4 1.2.3.4

I.e. it is one thing if ISP C have multiple copies of server 2.3.4.5 
which it own, and all copies are within the AS of ISP C.

My scenario is something different. I talk about ISP C hijacking 
traffic which B think should go to D, and it goes to C instead.

My view is that this _is_ ok, if both copies of 1.2.3.4 is handled by 
the same organization, so when A, or B calls the organization, they can 
check both servers and see they are in sync.

   paf

---

From: David Conrad <[email-masked]>
Date: Mon, 04 Nov 2002 08:51:04 -0800

Hi,

> the answer should be) it is very difficult to determine whether or not

Might be a good time to point out that I just revised the serverid draft to
add a bit more explanation and an example.  Diffs enclosed.  It should be
showing up sometime before Atlanta.  Given the lack of discussion on the
previous version (Ed wanted it to do something entirely different and Randy
got confused) I haven't indicated I need any time to discuss the draft in
Atlanta.

Rgds,
-drc

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 4 Nov 2002 19:58:04 +0100 (CET)

> to C reach that server, or the real 1.2.3.4 which is at D which B ask C

Ok.  Assuming that C's transit routers listen to C's internal routing,
then traffic to 1.2.3.4 from A will be directed to C:1.2.3.4, not
D:1.2.3.4 .  This is probably the most-likely case.

If C have Clue++, and have directed their transit routers to _not_ listen
to that specific internal announcement, then traffic from outside of C
will go (as non-C customers expect) to D:1.2.3.4 .

Traffic from C's customers (etc) will always go to C:1.2.3.4 .

--==--
Bruce.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 04 Nov 2002 20:44:35 +0100

- --On Monday, November 04, 2002 16:45:35 +0100 Patrik Fältström
<[email-masked]> wrote:

> My view is that this _is_ ok, if both copies of 1.2.3.4 is handled by the
> same organization, so when A, or B calls the organization, they can check
> both servers and see they are in sync.

I think this is a wise precaution. Anycast holds a lot of promise, but as 
always with the latest and greatest, there is risk.  Mitigating this risk 
by keeping the controls quite tight is good.  Having said this,  I notice 
that most of the Internet around me seems to be served by a "rogue" AS112 
machine[0],  not listed on the as112.net home page, and not set up to the 
usual AS112 standards, so this control is probably impossible to enforce. 
I however still think that we ought to try to get as many anycast servers 
for the crucial zones (esp. root) as possible to comply with some kind of 
cooperative control scheme.   Seek them out and have them join the flock.

- -- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

[0]	
$ traceroute blackhole-1.iana.org.
traceroute to blackhole-1.iana.org (192.175.48.6), 64 hops max, 40 byte
packets
 1  KTHNOC-1-GE6-0.sunet.se (192.36.125.1)  8.780 ms  2.465 ms  2.438 ms
 2  stockholm1-SRP4.sunet.se (130.242.94.8)  2.688 ms  2.644 ms  2.598 ms
 3  s-gw.nordu.net (193.10.252.181)  2.749 ms  3.989 ms  2.883 ms
 4  dk-gw2.nordu.net (193.10.68.38)  11.100 ms  10.912 ms  15.517 ms
 5  sl-gw10-cop-9-0.sprintlink.net (80.77.65.25)  24.712 ms  24.357 ms
16.482 ms
 6  sle-teledanm-1-0.sprintlink.net (80.77.65.30)  13.202 ms  11.21 ms
11.579 ms
 7  so-1-2-3.622M.albnxu1.ip.tele.dk (195.249.7.66)  13.539 ms  28.26 ms
11.936 ms
 8  so-0-0-0.2488M.arcnxu1.ip.tele.dk (195.249.7.237)  15.998 ms  17.719 ms
21.30 ms
 9  pos8-0.2488M.arcnxg1.ip.tele.dk (195.249.7.117)  14.765 ms  14.304 ms
14.780 ms
10  blackhole-1.iana.org (192.175.48.6)  19.989 ms  28.793 ms  23.670 ms
$

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 04 Nov 2002 21:23:36 +0100

- --On Monday, November 04, 2002 21:02:28 +0100 Jesper Skriver
<[email-masked]> wrote:

> It's after agreement with Paul Vixie - but it's been having stability
> problems in the past days, my collegue Michael should have fixed them
> today.

Oh, I assumed "rogue" because I did not see Tele Danmark in the AS112 web
pages and the "dig @prisoner.iana.org hostname.as112.net any" command did
not return what I'd expect. 

My apologies for jumping to conclusions. 

Hilsen/Regards
- --

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 05 Nov 2002 00:31:17 +0100

- --On Monday, November 04, 2002 21:40:09 +0100 Jesper Skriver
<[email-masked]> wrote:

> The reason it's not listed, is that we don't advertise it globally -
> only to peers in Denmark - but as this now include Sprint, traffic to
> the boxes increased significantly (peaks of 16 Mbps seen), causing the
> instability.

And I get them from Sprint to Nordunet in Copenhagen, as well as from
Sprint in Stockholm when I'm on my home ISP. (I also do remember seeing
Tele Danmark as an AS112 advertiser back during RIPE 42.) Your actions to
participate come in the right time, and this (to justify keeping the thread
on dnsop..) is a prime example of why global synchronisation of an anycast
resource (to prevent chaos and confusion) is vital.

One of the more compelling reasons for OOB communication regarding
operation of anycast systems is the potential for new services to be
directed to name servers within an already used anycast block. Those
operators not informed of this might end up auto-DoSing themselves, since a
potentially important part of DNS namespace now is pointed to something
they themselves are responsible for. Is there any prior thinking done on
this? 

I still believe that dnssec holds some of the necessary means to
reestablish whatever trust was lost in the deployment of anycast, but until
dnssec
is feasible and deployed, we need to talk and agree over suitable beverages
to make this work. (Not that we can stop talking operations after our holy
Grail of signed records has been carried in procession through the
breakfast halls of a suitable IETF meeting, but the uncertainity of data in
unsigned anycast makes it much more fragile -- with dnssec we know when the
data is broken, since the sigs won't match.)

/måns, pondering an AS112 setup for himself... 
- -- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

---

From: Brad Knowles <[email-masked]>
Date: Mon, 4 Nov 2002 18:42:03 -0600

>  note that the large isps have been running anycast caches (and some

	Route hijacking, yes.  Transparent proxying, yes.  True anycast 
for protocols other than UDP?  I sincerely doubt it.  If you have 
evidence for this, I'd love to see it.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 4 Nov 2002 18:40:08 -0600

>  the shortest path that your router sees.

	Right, but if the route changes in the middle of the session, 
you'll get a TCP connection reset by the different server, and you'll 
have to start that conversation all over again.  UDP survives anycast 
since it's a single packet.  TCP won't do so reliably, and therefore 
it is not practical to try to use TCP anycast.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 4 Nov 2002 18:47:15 -0600

>  when users have problems, they call their isp, just as they do now.

	Yeah, but if their ISP isn't the source of the problem?  What if 
the problem is one of the ISPs with which their ISP peers?  Or has 
transit traffic with?  Or some one that peers with their transit or 
transits for a peer?

---

From: Brad Knowles <[email-masked]>
Date: Mon, 4 Nov 2002 18:43:35 -0600

At 2:53 PM +0100 2002/11/04, Patrik Fältström wrote:

>  I definitely want one and only one organization owning/controlling
>  all copies of the same IP-address.
>

	Agreed.

	Joe Random ISP (or other company) should not be advertising that 
they are a particular IP address unless they have been given explicit 
permission by the original owner of that address to do so, and in the 
manner they are advertising.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 4 Nov 2002 18:49:42 -0600

>  been using anycast dns for many years.

	Again, I'd like to see evidence of this.  I can verify practices 
at a few large ISPs, and see if they've been doing it or not. 
Certainly, the large ISPs I am personally familiar with would never 
consider doing this -- indeed, the concept almost certainly would not 
even occur to them.

	If they have been doing this sort of thing, then there is a much, 
much more serious problem that I think we need to deal with.

	Note that I'm talking about true anycast, not route hijacking or 
transparent proxying.

---

From: Andrew Partan <[email-masked]>
Date: Mon, 4 Nov 2002 21:07:48 -0500

> warns them when one of the copies of Y give wrong data / is out of sync.

I have to agree with Patrik.  If there isn't some organization that
knows how this thing is deployed and knows all of the otherwise
hidden stuff, then this just isn't going to work.  Its going to
break and you will not be able to figure out why.

I remember watching the aroot experiment and there was no real
method to finding out how & why something was busted.  Thins just
sometimes worked & sometimes didn't.
	--asp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

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

> evidence for this, I'd love to see it.

So Brad, what is 'true anycast' ?  I'd really love to read your
definition, in addition to any implementation tips utilising common
routing protocols as found on the Internet.

Regards,

---

From: Robert Elz <[email-masked]>
Date: Tue, 05 Nov 2002 18:03:44 +0700

Date:        Tue, 5 Nov 2002 09:53:44 +0100 (CET)
    From:        Bruce Campbell <[email-masked]>
    Message-ID:  <[email-masked]>

  | So Brad, what is 'true anycast' ?

Not Brad, but:

Multiple (different) systems with the same IP address, where you cannot
predict in advance which system a packet to the address will arrive at
(that is, it all depends upon the state of the net at the precise instant
the packet is routed).

If you know that all the packets to address X from Y will (always) go to Z,
that isn't anycast, regardless of whether or not someone else's packets
to address X go somewhere different.

kre

---

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

> (that is, it all depends upon the state of the net at the precise instant

Right.  I've got two services that the RIPE NCC provides (www.ripe.net and
k.root-servers.net) which use local load-balancing or clustering to direct
UDP and TCP SYN packets in round-robin fashion to multiple back-end
servers ( continuation of a TCP stream goes to the same back-end server
for obvious reasons ).

With these two, I cannot predict ahead of time which back-end server will
handle a particular packet, with the notable exception of TCP streams as
described above.

There is a third service which the NCC also provides which also meets your
above criteria, being a server in the AS112 project.  Ahead of time, I
cannot predict where a packet destined for blackhole-1.iana.org (or
blackhole-2.iana.org) will end up, unless I have knowledge of the routing
table in effect for that portion of the Internet.

This is implemented using what you call 'route hijacking', where multiple
entities masquarade as origin AS 112, and advertise reachability to
192.175.48.0/24 (where the above-mentioned servers reside).  In practice,
routers keep track of the 'best' path for that prefix (since all the
advertisements are the same prefix and from the same origin AS, the
shortest path wins) and direct all packets down that best path.

> to address X go somewhere different.

Ok, let us assume AS112 advertisers X, Y and Z, ISPs A, B and C and
transit ASes of the rest of the alphabet.

Assume that routers at ISP A see the following path:

	192.175.48.0/24		T U V W X 112
*	192.175.48.0/24		T Y 112

Then ISP A will always choose the 'best' path of T, Y, 112 .  This isn't
anycast by your definition.

ISP B sees:

	192.175.48.0/24		H I J X 112   (received 1036501521)
	192.175.48.0/24		L M N Y 112   (received 1036501654)
*	192.175.48.0/24		P Q R Z 112   (received 1036500032)

With some routers, the last path would be used since it was received
first, other routers might use the last path (second listed) received
instead, and still others might start doing path selection based on the
lowest-numbered AS of the first hop (the first path).

Without knowing the router used and when the route announcements came in,
I don't know which path packets would use, thus this contrived uncertainty
meets your definition of anycast.

ISP C sees:

	192.175.48.0/24		E F G Y 112   (flapping)
	192.175.48.0/24		H I J X 112   (flapping)
	192.175.48.0/24		H Q R Z 112   (flapping)
	192.175.48.0/24		P Q R Z 112   (flapping)
	192.175.48.0/24		L M N Y 112   (flapping)

In which case I don't know which path ISP C will use, as all of its routes
are unstable (in practice, the router would choose the 'most stable',
which is dependent on timing of route flaps).  This (again contrived)
instability would also be anycast by your definition.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 07:52:04 +0859 ()

Paf;

> warns them when one of the copies of Y give wrong data / is out of sync.

An operator of an anycast server is identified by a unicast address
a router adjacent to the server.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 08:08:08 +0859 ()

Brad;

> it is not practical to try to use TCP anycast.

For query, which is short, TCP is fine.

For zone transfer, it is insecure to rely on anycast addresses.

If you are supplied forged data, you can't later identify which
identity supplied it.

Use unicast address of the anycast server, details on which are
described in my ID.

							Masataka Ohta