Hello, I happened to read through a few older anycast-related drafts; a few comments, to try to spark some discussion on how to go forward with anycast. Last, I bring up one idea how to possibly make TCP+anycast work, in relatively simple terms.
1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using MLD) -- May 2002. ==> basically the MLD protocol is used to signal anycast joins/leaves. However, critical part which seems to be missing here is "interactions of anycast-MLD with routing", as with multicast. There are a _lot_ of issues there, especially if one anycast address can have joins from across multiple routers. Even more so if from across multiple sites/AS's, or more specifically (with some terminology pixie dust) an IGP/iBGP area -- a region where propagating host routes is acceptable. But I'd recommend sticking to a site, the rest is way too difficult for now. Thus by far the easiest way to enable anycast on hosts seems to be a requirement for them to participate in a routing protocol. Something like BGP is good for this (not ideal: too much weight). Simpler protocols can of course also be used; the most important thing is to pick one which allows your neighbor(s) to filter out any advertisements excluding the anycast addresses(es) -- so that you can't hose the routing to other than the anycast address(es) itself even in the worst case scenario. A few points on security: 5. Security Unlike multicast, allowing nodes to join arbitrary anycast groups can result in denial-of-service attacks. Whereas joining a multicast group does not prevent other nodes from seeing the same traffic, joining an anycast group can cause traffic previously seen by another node to be redirected to the newly joining node instead. ==> of course, this is more than just DoS. This is packet capture and a man-in-the-middle attack too. To prevent such attacks, it is expected that routers will employ some filtering mechanism when receiving a Report message containing a non-multicast address. For example, one policy might be to deny all anycast joins except those that match a configured list of (source address, anycast address) pairs. ==> the problems with such a measure seems to be that: 1) MLD message does not signify other than link-local addresses AFAIR 2) some addresses are easily spoofed. Of course, to be complete, some "reverse-path verification" for addresses, if routable unicast, would have to be done. 2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using Return Routability) -- Oct 2002. ==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping update but the concept is clear. However, I'm just not so sure that this is the right, even if seemingly sufficient, approach. The main concerns from the top of the head seem to be: - the extent of MIPv6 support required to support this (I assume e.g. binding cache is needed) - the high number of packets exchanged before commencing with real TCP traffic - the changes to TCP to run this operation at the reception of a specific TCP SYN (perhaps this happens with MIPv6, but my impression has been that in most cases, return routability is executed based on MN's own desire to do send packets, not respond to some of them) - the different model of address ownership model; this seem the most important. MIPv6 RR is used to prove that the MN has the right to use certain care-of/home address. These are network-topology -independent, in a sense; a part of an autoconfigured/statefully-configured prefix, freely configurable by anyone on the link(s). Anycast is different: there the right target to ask for permission to certify this binding would appear to be the routing system, or someone in charge of specifying the <anycast, unicast> -pair. It appears that here the link between the routing system is not all that strong (e.g. some MLD-like mechanism or injected static host route), but could perhaps be acceptable (note: these kind of assumptions should go in the draft :-). 3) that's it. My own, very raw idea for anycast + TCP: a new ICMP message, including the seq number (or equivalent protocol-specific information) of the just-received TCP SYN, indicating the unicast address which should be used instead of the included anycast address. Of course, this brings up the problem of easily-guessable TCP seq numbers. This could be mostly remedied by requiring (I wonder if this kind of requirement would be sane..) that TCP implementations check their SYN_SENT state tables that the packet has actually been sent to the the destination very recently -- thus the window where a timing attack could be done would be almost eliminated. As an option, if the initiator would not believe this binding, some stronger mechanisms could be applied (source address comparison, which is not really valid except if we apply some new requiremens for anycast usage -- like that to be used like this, the addresses must all be from the same /64, /48, /32 or whatever *); RR tests; etc.). Of course, all of this would appear to be moot if something like IPsec was used between the end-points. So basically, this looks like a MIPv6 binding update but including the no-so-strong TCP seq number and sender TCP state and other data as a quite probable sign of validity. I'd like to know whether anyone has tried to tread down this path and come up with some unsurmountable obstancles...? *) or even prefix length configured with some bits set in the anycast address, a bit similar to draft-savola-mboned-mcast-rpaddr-00.txt. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
