Re: national security
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: national security
On 7 Dec 2003, at 07:21, Iljitsch van Beijnum wrote:
I don't think this is an oversight, I'm pretty sure this was
intentional. However, since in practice the BGP best path selection
algorithm boils down to looking at the AS path length and this has the
tendency to be the same length for many paths, BGP is fairly useless
for deciding the best path for even low ambition definitions of the
word.
For the service aspects of F we're more concerned with reliability than
performance. Recursive resolvers ask questions to the root relatively
infrequently, and the important thing is that they have *a* path to use
to talk to a root server, not necessarily that they are able to
automagically select the instance with the lowest instantaneous RTT
(and continue to find a root regardless of what damage might exist in
the network elsewhere).
For example, local routing policies might lead a resolver in South
Africa to select a path to 192.5.5.0/24 in California over the node in
Johannesburg under normal operation. We hope, though, that in the event
that the resolver becomes isolated from California, a path exists to
Johannesburg which will allow F-root service to continue reliably (and,
for example, to allow names under ZA corresponding to local, reachable,
services to continue to resolve).
The selection of anycast node has more importance when you consider the
other, non-service role of F, which is to sink attack traffic: we'd
like to sink attack traffic as close to its source as possible.
Fortunately the rough-hewn and clumsy hammer of BGP path selection
seems good enough to attempt to attain that goal right now, since our
routing policy generally leads people to favour a local node (peer)
over a global node (transit) through application of pre-existing
routing policy. This is a natural result of the common truth that
peering paths are cheaper than transit ones.
Joe
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.