Pekka Savola wrote:
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.
Sure. I was referring more to the routing issue. Within a site,
the scale of propogating the authentication information is much
smaller and better understood.
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.
So would I, except it is supported today in v4.
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.
One possibility is an ICMP option that includes an authentication
key or some dependency on SEND.
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..?
It sounds like you want to restrict anycast members to a single
link or that an anycast prefix has to be configured on multiple
interfaces around the network.
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.
So, for intra-site the extra messages are OK but not for inter-site
anycast?
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.
In order for the client to verify the authentication information in
the ICMP message, we would need a key distribution mechanism.
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.
The big issue is how will anycast be used. In general, I see it as a
discovery mechanism. Once an anycast server responds, the client uses
the server's unicast address for communication.
Other views?
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]
--------------------------------------------------------------------
