Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 6 Apr 2005 16:09:24 -0400

From: Joe Abley [mailto:[email-masked]]

> Correct. However, the v6 addressing spec prohibits the use of an 
> anycast address from being used as the source address in a 
> datagram, or 
> being bound to an interface on a host. These two restrictions 
> effectively prohibit the use of anycast as a service distribution 
> mechanism.

Any reason why the same rules that apply to multicast addresses wouldn't also work here?

The destination address is anycast, to find the service. But the source address in the reply is the unicast address of the first server to respond, which presumably is the closest one at the time.

This may circumvent the authentication issues, by making any subsequent TCP session start as a regular unicast?

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Apr 2005 16:57:10 -0400

> Any reason why the same rules that apply to multicast addresses 

Actually, yes.

Anycast is being used to deploy services which, to clients, appear 
identical to normal unicast services. The protocols used are varied, 
and widely deployed (e.g. DNS, HTTP).

Clients source datagrams with a destination address set to the service 
address, which in the cases we are discussing are deployed as anycast 
addresses (i.e. they are present on more than one interface, usually on 
different hosts). The clients have no way of knowing in advance whether 
the destination addresses they are using are deployed on just one 
interface (in which case we are talking about unicast) or more than one 
(anycast).

> The destination address is anycast, to find the service. But the 
> source address in the reply is the unicast address of the first server 
> to respond, which presumably is the closest one at the time.

That might be a reasonable way to design a new protocol to be deployed 
using anycast (although I think the security implications might bear 
close scrutiny), but it's not a reasonable way to distribute services 
which use existing protocols.

To use DNS as an example, a DNS resolver sends a request to a 
nameserver using a particular destination address, and expects the 
reply to be sourced from the same address. If the reply was sourced 
from a different address, the client (resolver) would not accept it as 
an answer to the original request.

Joe

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 13:52:09 -0700

doesn't work. When TCP sends a SYN to the anycast address, it can only 
identify the SYN-ACK by having the source address of the SYN-ACK be the 
anycast address.

The mobility model that Joe and I discussed requires a security 
association to be set up with the anycast address (IPSEC management 
protocols reply with the anycast address as a source), supply a COA, 
and then TCP is set up to the COA.

But we still have to get a message from the anycast server that somehow 
says "I am a valid responder to that anycast address, but use this 
other address instead during this session."

On Apr 6, 2005, at 1:09 PM, Manfredi, Albert E wrote:

> This may circumvent the authentication issues, by making any 
> subsequent TCP session start as a regular unicast?
>
> Bert
>

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 08 Apr 2005 16:58:04 -0700

Fred Baker wrote:

> protocols reply with the anycast address as a source), supply a COA, and 
> then TCP is set up to the COA.

FWIW if you believe that routing is trustworthy, i.e. that packets only 
get delivered to the hosts that are somehow authorized to receive for 
that anycast address, then it would suffice to use the return rout 
ability property for securing things, just as in MIPv6.

The only downside to this is that today the only way we have to 
authorize anycast receivers is by manual configuration in the routers 
that inject the routes for the anycast addresses.

Applying IPsec doesn't help solve the authorization issue of who should 
be allowed to receive packets sent to a particular anycast address.

    Erik

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Apr 2005 18:06:32 -0700

On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:

> Applying IPsec doesn't help solve the authorization issue of who 
> should be allowed to receive packets sent to a particular anycast 
> address.

Can you tell me any address or type of address for which that is an 
objective either of internet routing or addressing?

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 08 Apr 2005 18:38:57 -0700

> objective either of internet routing or addressing?

I guess I don't understand the question.

The way I use "authorize" in this context is best shown in this example:
For regular unicast, the fact the my ISP has assigned a /29 to me, and 
inserted that in their routing tables manually, means that the DSL line 
to my house is authorized to receive packets addressed to that address 
prefix.

This coupled with trust in the ISPs that run BGP (but not necessarily 
much security) we are pretty confident that packets sent to one of 
google's IP address in fact get routed to one of google's machines (or 
dropped under overload).

Enter anycast. If we try to design a protocol mechanism by which any 
host can say "send me packets for this anycast address" and with anycast 
addresses being syntactically indistinguishable from unicast, what would 
prevent my laptop from saying it wants to receive packets addressed to 
one of google's unicast address?

Thus my point is that any grand unified approach to anycast needs to 
think about the authorization issues.

Of course, this isn't a problem in the way IPv4 anycast is used for DNS, 
because there is manual configuration hence implicit authorization of 
which DNS servers are part of the anycast sets.

    Erik

---

From: "James Kempf" <[email-masked]>
Date: Sun, 10 Apr 2005 17:58:47 -0700

> objective either of internet routing or addressing?

It is possible to determine authorization to use an address with CGA. RFC
3972 describes how to construct a CGA and its security properties, RFC 3971
describes how to use them to secure the resolution of link addresses to IP
addresses in Neighbor Discovery (i.e. SEND). There is also an individual
draft that describes how to use CGAs for securing Mobile IPv6 binding
updates (grep for "OMIPv6").

            jak