sorry that i missed the i-d deadline for this.
note that the document is in IESG queue for a lo---ng time.
>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.
if "shared-unicast address" is more common, i'm happy to use that term.
>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'll update the draft to refer RFC3258 and make necessary adjustments.
i'm not sure if i should keep references to mohta-san's draft.
>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 guess title of section 3 was vague - "current proposals" tries to mean
"current proposals made for IPv6", like RFC2373 limitation for IPv6
anycast address assignment. therefore, 3.3 talks about restriction
imposed by RFC2373, which is applicable to IPv6 only.
i'll update title of section 3 to be more clear, and make sure to
remove any IPv4 topic from section 3.
>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.
the paragraph tries to say:
- if we use predefined site-local anycast address, the propagation of
host route (/128) would be limited within the site, therefore it may
be permissible (depending on the routing table size of the site)
- if we use predefined global anycast address, host route needs to be
carried worldwide and we will see problems like you mentioned above.
how should i word it for clarity?
>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.
then i would need to write up a separate dnsext document for the
removal of the check. ok, i'll try to do that.
>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.
quoting RFC2181:
>> will be able to use it for further queries. Servers configured in
>> such a way that not all their addresses are equally reachable from
>> all potential clients need take particular care when responding to <---
>> queries sent to anycast, multicast, or similar, addresses. <---
from the above text, it is clear that client should/can not check the
source address of the reply in the above case.
>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.
routers will know that the host is authorized to inject a route to
the routing system, by the fact that it knows the shared secret
used by the routing protocol (if the route is advertised with proper
authentication encapsulation/extension header, it is authorized).
do i need to be more clear on such trivial thing? if so, how?
itojun
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
