Subject: Re: a few comments on anycast mechanisms

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 14:43:37 +0100 (CET)

> 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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Feb 2003 09:14:46 +0200 (EET)

Hello,

Sorry for the delay in responding.

> 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).
 
> > the anycast address(es) itself even in the worst case scenario.

Yes!
 
> 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").

> "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 

Possibly some TCP modification.  I'm not sure if there are others.
 
> 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..
 
> 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.
 
> I must have missed the document which specifies how IPsec works with anycast

"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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 11:07:14 +0100 (CET)

> with the routing protocols.

I thought you just agree with me that the security/auth issue is independent
of the protocol used.

> know have an explicit toggle to disable/enable packet forwarding between 

I wasn't concerned about that but accidentually getting the host
to pass routes in the routing protocol between its interfaces.

> Possibly some TCP modification.  I'm not sure if there are others.

What about UDP, SCTP, DDP?
Minimizing transport awareness of anycast seems like
a reasonable approach to me.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Feb 2003 17:13:43 +0200 (EET)

> I thought you just agree with me that the security/auth issue is independent

Well .. it is, in a sense that security/auth must be done _somehow_, _but_ 
certain protocols (like BGP) already provide this functionality to 
the sufficient degree.
 
> to pass routes in the routing protocol between its interfaces.

You've configured the routing protocol wrong in a few places (host itself, 
and it's neighboring routers: they must have access lists to prevent 
everything but the anycast announcement) if this happens.  With IGP's it's 
easier, but I'm not really advocating one due to signicantly more 
difficult control mechanisms.
 
> a reasonable approach to me.

For connection-oriented protocols, similar modifications would have to be 
done.  Note that e.g. in SCTP this might not be a problem -- because there 
is already a concept of multiple addresses -- anycast could just be one 
which is never really used.

For connection-less protocols, source address should not matter, that 
much.

But certainly, I agree that "protocol independence" has certain value :-).  
But it also has a price tag attached to it..

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 16:03:33 +0100 (CET)

> For connection-less protocols, source address should not matter, that 

The fact that UDP is a connection-less layer 4 protocol doesn't mean
that there aren't protocols above it which assume that they
continue to talk to the same peer (until communication fails).

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Feb 2003 17:31:56 +0200 (EET)

> continue to talk to the same peer (until communication fails).

This can also be turned the other way around: for such protocols, 
connection failure signals the need to re-establish this 
"pseudo-connection".

This is a big problem only if the anycast group is flapping severely, it 
seems to me.