> 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.
I agree that there are issues like that. But those issues are independent of the protocol mechanism (MLD, RIPng, OSPFv3, ISIS, BGP - gawk!) that is used to carry the routes from the host to the router. The authorization independently of the protocol. > 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. BGP??? I think there is some operational experience that configuring a routing protocol on the hosts for the sole purpose of announcing one or more (anycast) source routes adds a lot of complexity. Not only does the host need to implement a routing protocol which interoperates with what the routers run, you also need to prevent the host from ever being used for forwarding. If the host is multi-interfaced this might be quite tricky and error prone. Thus having a separate host-to-router protocol with limited functionality seems to make sense to me. > ==> of course, this is more than just DoS. This is packet capture and a > man-in-the-middle attack too. Yep. > 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. How would reverse-path help with the authorization issue (which node can "join" e.g. the "sun-ntp-server" anycast address? Short of CGA techniques (where the host would be challenged to prove that it has the private key corresponding to the CGA anycast address) I don't see a scheme which doesn't require manual configuration of an access list on the router. > 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) yep > - the high number of packets exchanged before commencing with real TCP > traffic And the alternative is? > - 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. I think that is the local problem - the first-hop router next to the anycast server. And that needs to be solved with some form of access control list. But even if that is solved it doesn't help the initiator of long-term communication with an anycast address to safely know the mapping between the anycast address and one unicast address which is part of the anycast group. The use of return-routability allows you to make statements about that binding with the same security level as for the MIPv6 return routability. > 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. And you have the option of the target to bomb a victim by saying "send your packets to Alice" even though Alice is not part of the anycast group. The use of RR prevents this, as well as provides something stronger than the TCP sequence number from a guessing perspective. > 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. I must have missed the document which specifies how IPsec works with anycast addresses :-) 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 PROTECTED] --------------------------------------------------------------------
