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.
Correct. At the time, the intent was to gauge interest in this approach and then introduce guidelines on how routers should deal with the information.
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. 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.
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.
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.
Yes.
==> 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.
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?
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.
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)
Yes.
- 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.
- 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)
MIPv6 has to work in either direction. The use of return routability here is to signal the mapping of anycast<-->unicast.
- 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.
Erik and I had a discussion on this point. The RR messages are meant to signify to a client that the mapping is valid. That is, a rogue couldn't inject someone else's unicast address in the RR message. If the anycast server can be verified by the first-hop router, then it could be possible from some indication be sent from the router. This depends on having some group authentication capability in the server<-->router signalling.
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 :-).
Agreed. However, part of the reason for the lack of advancement in this area has been the lack of interest from other people. Feedback and suggestions on these drafts are greatly appreciated.
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.
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.
Setting up an IPv6 anycast WG has been discussed in the past. Perhaps if there is interest, we could pursue it again. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
