Hello,
Sorry for the delay in responding.
On Tue, 18 Feb 2003, Erik Nordmark wrote:
> > 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.
Totally agree here: the crux of the problem is the authorization (and
AFAICS, it is not a small problem -- contrary to the multicast model).
> > 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???
Yes!
> 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.
I seem to have a different opinion. To me, configuring BGP is very simple
operation: you can be sure how it works, and the basic configuration is
easy to do.
On the other hand, I'm very worried about specifying a host-router
protocol, as it is a new protocol -- contrary to working operational
practise -- and has a number of difficult issue to tackle with, most
important of them perhaps the security/authorization and interaction
with the routing protocols.
I fail to see an issue with multi-interfaced hosts: all implementations I
know have an explicit toggle to disable/enable packet forwarding between
interfaces ("routing").
> > 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?
I'm making the assumption that either:
1) anycast addresses are defined from the same subnet as the anycast
nodes reside in, or
2) authorization of anycast address joining must be completely manually
configured
In the first case, consider the subnet 2001:db8::/64. Two nodes have
unicast addresses 2001:db8::1 and 2001:db8::2 there. They want to
participate in anycast group 2001:db8::53.
Now, the router would check the unicast route it has to "2001:db8::53".
That points to interface with 2001:db8::/64. In consequence, it only
allows anycast joins to the group "2001:db8::53" from 2001:db8::/64.
But of course, this case of anycast usage is not all that interesting I
think -- most probably want to have the anycast nodes deployed on
different subnets.
Another (and additional) variant of this is performing a uRPF check on the
unicast address. That is, if an anycast group join is said to come from
2001:db8::3, check that it arrived from the interface where the route to
that destination points to.
> > - the high number of packets exchanged before commencing with real TCP
> > traffic
>
> And the alternative is?
Possibly some TCP modification. I'm not sure if there are others.
> > - 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.
That isn't a big problem, I guess -- if anycast servers are deployed
behind a single router. Otherwise it gets hairier..
> > 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.
Yes, but RR does not come without a cost. TCP sequence number, coupled
with a very short window and a limited number of tries, seems rather safe
even if TCP seqno would have not base itself on a strong PRNG.
> > 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 :-)
"Works" is relative :-). I was referring to the process of sending an
initiation of communications to the anycast address, and _then_ enabling
ESP-protected IPsec communication to the unicast address -- ie, no problem
there. Of course, there may be a slight problem of having keys to all the
unicast addresses behind the anycast address, but I don't see that as a
huge problem with IPsec keying problems as is.
--
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]
--------------------------------------------------------------------
