Subject: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Feb 2003 17:37:33 +0100 (CET)

I've finally re-reviewed draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt.
I have some concerns about clarity as well as strong concerns about
the document seeming to change the standard for DNS clients verifying the
source address of the replies. Details below.

RFC 3258 uses the term "shared-unicast address" for what you seem to be calling
"pseudo-anycast". I wonder if it makes sense using this existing term instead
of creating a new one.

RFC 3258 talks about an organization using anycast internally while speaking
BGP to the external world, yet in section 2.2 you bundle this with
draft-ietf-dnsop-ohta-shared-root-server-02.txt and seem to say that
they both cross AS boundaries. As I understand it the technical difference
between 3258 and shared-root-server is whether it is contained within one AS
or not. Thus it would make sense to make this more clear in the document.
Currently section 2.2 seems to only speak about the ohta approach, and
my understanding is that the RFC 3258 approach is more widely deployed for DNS.
I think RFC 3258's shared-unicast approach is quite useful given the
constraints it imposes on itself:
 - used for DNS lookups i.e. short transactions
 - that the DNS has a failure recovery mechanism (through multiple NS records
   and multiple nameservers in resolv.conf) which provides failure recovery
   even though the routes are not withdrawn when an instance of the 
   shared-unicast service dies.

To make this more clear you can either remove the mention of BGP and
"distant domains" from section 2.2 or you can make it clear what the Hardie
and Ohta-san documents have in common and what is different (with the "distant
domains" being the difference).

I think it would be very useful to point out in section 3.3 that there
is nothing inherent in IPv6 that prevents the use of pseudo-anycast -
the issues listed in section 3.4 apply to both IPv4 and IPv6.
I don't think there is WG concensus to endorse such behavior for IPv6
even through the scheme used in the Hardie and Ohta-san documents would work
just as well (or poorly) in IPv6 as in IPv4.

I don't understand what the last paragraph in section 4.1 is trying to
say. Clearly carrying /128 routes for anycast word-wide doesn't scale for
arbitrary use of anycast (but having explicit routes e.g. for DNS root servers
isn't an abitrary use since the set of addresses would be very limited).
Whether site-locals or globals are used it is required that the anycast
addresses aggregate into existing prefix routes at some scale.
But is the paragraph trying to say that this is some improvement that is
needed? (It is in a section about possible improvements.)
It can be read as this being something that needs to be fixed, but I think
it is just a fundamental constraint whether anycast addresses are assigned
to only routers or also to hosts. Thus the point seems to belong in section 1.

Section 5.1 says:
   Note that, however, bad guys can still inject fabricated results to the
   client, even if the client checks the source address of the reply.  The
   check does not improve security of the exchange at all.

This seems counter to the wisdom that lead to requiring the addresses
to match, yet you don't refute those arguments.

I think in reality the (very spotty but existing) application of ingress 
filtering in the 'net means that the DNS requirement on matching addresses
in requests and replies provide a non-zero security improvement.

I think it is a bad idea to have an informational document like this
try to change the DNS protocol practise to not check the source address of
the reply. If you want to change this we need a standards track document.
Having this informational document discuss the issue of source address
checking is fine, but it isn't fine that it effectively removes it.

o For many of the existing protocols, we cannot perform sanity checks
  using IP source address address.  More specifically, for UDP DNS
  replies against queries to anycast address, it is not recommended to
  check source address, based on RFC2181 section 4.1.

I don't see any text in section 4.1 in 2181 that recommends changing
anything on the client. In fact section 4 and 4.1 is how to make
servers work with clients that do verify the source address of the reply.
Thus I can't see how you come to this conclusion.

Section 7:
  For secure anycast operation, we may need to enable security mechanisms
  in other protocols.  For example, if we were to inject /128 routes from
  end hosts by using a routing protocol, we may need to configure the
  routing protocol to exchange routes securely, to prevent malicious
  parties from injecting bogus routes.

"exchange routes securely" reads like securing the exchange of the routes
between the host and the router. That is useful but inadequate. The difficult
problem is how the router knows which host is *authorized* to inject
a route for which anycast address. Securing the communication between the host
and router doesn't solve the authorization problem. It would make sense to
point this out as an unsolved problem (short of manual configuration) in
the draft.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------