On Mon, 27 Jan 2003, Brian Haberman wrote: > > 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. > > Within a site it is no big deal. Routers with attached anycast members > would inject a host-route for the anycast group into the IGP.
Well.. there are some issues, like propagation of <source,anycast> validation information everywhere. > The big issue is with inter-site anycast. A host route from a foreign > domain (i.e. not the prefix owner) could actually prevent anycast > traffic from reaching the owning domain unless explicit config allowed > for the "leaking" of the host route out of the home domain. I see this as something that should be explicitly defined out-of-scope for these kind of anycast mechanisms. > > 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. > > One point of feedback we got from Itojun was that he preferred having > the hosts participate in the routing protocol (typically an IGP). No > one else has really stated an opinion on this work. I deem most IGP's insecure as the compromise of one node can do too much harm. Therefore using iBGP w/route-reflection as an "IGP" with strict route-map's in the neighbors controlling the advertised information seems vastly preferable. > > ==> the problems with such a measure seems to be that: > > 1) MLD message does not signify other than link-local addresses AFAIR > > Not sure what you mean. Are you referring to the use of link-local > addresses in the IP header? The group address within the MLD packet > can be of any scope. Source addresses, yes. Otherwise anyone on the link could join an anycast group. Granted, without SEND, one could still do some hackery and capture the traffic anyway, but having some protection rather than nothing would be useful. > > 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 so? If a host joins an anycast group, it could be using any > unicast address. What is the reverse-path check being done on? The unicast address. The point is to restrict those who can join to a group to only a few, legal unicast addresses. And that those MLD joins to a group using unicast address X would actually require that X would be routed to the interface/subnet from where the MLD join came from (otherwise -> bombing/DoS attacks). Or was there some misunderstanding..? > > 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. > > Agreed. I have not had time to update this work yet. I wouldn't worry about that much yet.. > > - the high number of packets exchanged before commencing with real TCP > > traffic > > What is high? The figure on page 2/3 shows a total of seven messages > that have to be exchanged in order to establish a TCP session. These > messages would be needed for MIPv6 as well. Depends on the scope, of course. To me, exchaning 7+3 messages just to open a TCP session seems like a lot. Especially when most, effective anycast+TCP traffic should be short-lived (so routing changes do not become a significant problem). OTOH, anycast is currently applicable in site-internal traffic only where you can expect low network latency, ie no big problems except for the packet overhead. > > 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. > > My original thought was to signal back the mapping using ICMP. The > mapping authentication capability of the RR procedure gives a better > level of security than a plain ICMP message. I agree with you here .. but ICMP could give you enough strong authorization with basically zero added messages. That would depend a bit on the strength of initial sequence number and relatively short-lived SYN_SENT data. I believe this could be an acceptable tradeoff. This could be further remedied by specifying that if more than X (e.g. 3) wrong ICMP packets would be received pertaining this connection, the rest would be ignored; this would be then have the success probability of about 3*2^-32 (best case scenario). In the worst case, not much different than remote TCP sequence number guessing anyway. TCP could also send an authentication token destination option (including a stronger SYN), of course, but that would require anycast be distinguishable before sending the initial TCP SYN: a non-starter. > Setting up an IPv6 anycast WG has been discussed in the past. Perhaps > if there is interest, we could pursue it again. Well, anycast doesn't seem to be progressing otherwise, but I'm not sure whether there's enough push for it (ie. could it be required by enough autoconfiguration etc. mechanisms to be worth the effort).. the only I could see it going forward would be as a separate WG. -- 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] --------------------------------------------------------------------
