Subject: RE: Anycast Addresses being used for Nodes not just Routers

From: "Bound, Jim" <[email-masked]>
Date: Thu, 2 May 2002 10:15:11 -0400

I agree.  Lets begin to work on getting a SHOULD that would fix it completely.

I will follow your lead in the WG so lets do it ............

/jim

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 2:28 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: Anycast Addresses being used for Nodes not just Routers
> 
> 
> On Wed, 1 May 2002, Bound, Jim wrote:
> > What do we think we need to do to get the requirement that 
> only Routers
> > can have anycast addresses changed to "nodes".
> > 
> > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example 
> of the use of
> > anycast for non-router systems that are very important for 
> the Internet
> > and IPv6.
> 
> I've been trying to push the changing of this:
> 
> 	o An anycast address must not be assigned to an IPv6 host, that
> 	  is, it may be assigned to an IPv6 router only.
> 
> in addr-arch-v3-07 to change 'must' to a 'should' for some 
> time now, with 
> not much progress.
> 
> I think this is one item that should be changed before 
> addr-arch is done 
> with in the IESG and locked for a few years.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 

--------------------------------------------------------------------
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: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 May 2002 09:33:05 -0700

Hello folks,

I think this is a great idea.

Furthermore, on the topic of letting packets have Source IP
address be the address of an anycast group, I think that it's
the responsibility of the particular anycast group to handle
all the ramifications.  It would be nice to have an Internet
Draft that lays out all of the canonical ramifications.

In the case where there is only one element of an anycast group,
and it has one of the "well-known" anycast numbers on its subnet,
this seems to be very natural and beneficial.  There would not
be a need to make the restriction for short session lifetimes.

If the anycast group can have several members, but still is
addressable at one of the "well-known" anycast numbers, then
we can require a standard specification for the operation
of the anycast group, including any such features as use of
the anycast address as a Source IP value.

Similar considerations hold for security, and even mobility
of the anycast group.  In fact, with enough calculation, we
might even be able to find some CGA-able anycast groups within
some lucky subnets!

Regards,
Charlie P.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 02 May 2002 15:02:26 -0400

Charlie,
     I had actually started taking a crack at this whole problem.  It
seems to me that the following components are needed for some form of
global anycast support:

     1. Host-to-router notification protocol (this is taken care of by
        changes to mld proposed in draft-haberman-ipngwg-host-anycast)

     2. Security: at a minimum some form of authentication to allow
        routers to determine if hosts are allowed to join an anycast
        group

     3. An Anycast Architecture doc that pulls all the pieces together
        and concretely describes how pieces interact, the pros and cons
        of anycast usage for intra-domain and inter-domain

     4. Possibly a draft that documents any impacts on any existing
        protocols (routing protocols, TCP, etc.)

Now, I have not spent time on the subject in the last 4-5 months, so I
have not gotten much past this list.  It is crucial that most of the
issues raised by Itojun's anycast analysis draft be addressed.

It should also be noted that this is probably way too much work to do
in the IPv6 WG.

Regards,
Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 May 2002 12:26:07 -0700

Hello Brian,

Your points are very well taken.  My main suggestion for the
immediate term was to relax some restrictions on well-known
anycast addresses located in their subnets.  It is really
easier if there's just one host, too.  The other things
will take more work.

From that context, I'll just add a few more comments inline:

>         changes to mld proposed in draft-haberman-ipngwg-host-anycast)

What happens if you have a host on a link responding to an anycast
address on that link?  Then other hosts on that link won't be able
to easily discern whether the router "liked" the anycast addressable
host or not.  I can imagine some very nasty ways to avoid even this
scenario, but I can't believe we'd really want to enforce them.

>         routers to determine if hosts are allowed to join an anycast

Similar comment to the on-link case for (1).  Furthermore, the
security requirements for an anycast group depend on the nature
of the anycast group, don't they?  It might typically be quite
unimportant to securely restrict participation in an anycast
group geared towards local broadcast of streaming audio of classical
guitar music, or a webcam of the cows in the pasture.

>         of anycast usage for intra-domain and inter-domain

Right!  But the latter is often true for any service.  The anycast nature
of the addressability of inter-domain isn't appreciably harder, otherwise,
than handling anycast groups in general, is it?

>         protocols (routing protocols, TCP, etc.)

This would be very important.

> It should also be noted that this is probably way too much work to do

It's way too much work for me too :-)  I'm not really suggesting that
the general case be made completely open prior to this work getting
done.  I was more suggesting that there are useful special cases that
do not present any appreciable downside.

Regards,
Charlie P.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 02 May 2002 16:31:37 -0400

Charlie,

> scenario, but I can't believe we'd really want to enforce them.

I haven't thought it all through, but perhaps there is a way to
handle the on-link case with ND.

> guitar music, or a webcam of the cows in the pasture.

Definitely, the nature of the group will help determine the security
requirements of that group.  However, I would not advocate the use of
anycast for some of your examples. :)

The security requirements of membership in an anycast group, I believe,
is much more important than multicast security requirements.  The
primary reason is that a rogue node can launch a very effective DoS
attack by joining an anycast group.  Since the packet goes to one
member of the group, a rogue can easily blackhole traffic to the
group for portions of a network.

> than handling anycast groups in general, is it?

It is harder in the fact that the current mechanism of anycast routing
requires host routes.  In the intra-domain case, anycast routes may
still aggregate, but that may not be true inter-domain.  Especially
when members of the same anycast group span multiple, independent
networks.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 May 2002 23:47:12 +0300 (EEST)

>         routers to determine if hosts are allowed to join an anycast

You're making assumptions here.

Hosts could very well participate in routing protocols.

I don't think Host-to-router protocols and security can be _practically_
dealt in the short/mid-term (<2-3 years).

>         protocols (routing protocols, TCP, etc.)

Unicast RPF is capable of killing anycast with source addresses quite 
effectively.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 02 May 2002 19:58:55 -0400

Pekka,

> Hosts could very well participate in routing protocols.

I don't think I am making assumptions.  If a node is injecting routes,
it is a router.  It may not be a member of the trusted set of routers
though.  That is where the security comes in.  If operators want to
protect the set of nodes that can inject routes, they can do so by
securing the routing protocol exchanges.

> dealt in the short/mid-term (<2-3 years).

I am not sure if I agree with that.  Today an operator can secure
routing
protocols.  And I envision that the number of services reachable via
anycast will be small and operating on an operator-trusted set of nodes.
In that scenario, I can see the host-ro-router protocols being made
secure.

> Unicast RPF is capable of killing anycast with source addresses quite

Not sure I follow you.  The anycast addresses are in the destination
address field.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 3 May 2002 10:25:13 +0300 (EEST)

> securing the routing protocol exchanges.

No, if a node is injecting routes, it needs not to be a router, as 
specified in RFC2460 and referred to in addrarch.

The definition:

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.  [See Note below].

DNS servers could participate in the routing protocol, injecting a route 
to itself, while still being hosts.

Usually the definition of router also includes forwarding packets between 
interfaces, but that's only implicit here.

> Not sure I follow you.  The anycast addresses are in the destination

You mentioned a host-to-router notification protocol, so we're discussing 
what would be different if anycast requirements are changed (not as a 
source address, not on a host).

Anycast addresses as source addresses (if allowed) have some amount of 
problems.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 03 May 2002 06:50:15 -0400

> interfaces, but that's only implicit here.

I am not disagreeing with what you are saying.  I was pointing out
that if a host is injecting routes then an operator would be wise
to ensure that the host is a trusted entity (i.e. uses authentication
keys in the routing protocol messages).

> Anycast addresses as source addresses (if allowed) have some amount of

Actually, all of my work so far has been based on the assumption that
the rule about anycast addresses being in the source field will not
change.

Here is a very quick example:

     A ------ Rtr1 ----- Rtr2 ----- B

A wants to join the anycast group FEC0::1234.  It sends an MLD Report
containing that address in the Group Address field.  The Report is
sent with an Authentication Header based on the group address.  Rtr1
receives the Report and validates the key.  If the key is correct,
then Rtr1 can inject a host route for FEC0::1234.  Now, when B wants
to communicate with FEC0::1234, Rtr2 will know to send the packets
via Rtr1.  The response back from A will use A's unicast address in
the source address field.  How will B know that the response came
from a member of FEC0::1234?  Well, one possibility would be to have
a Destination Option similar to the Home Address option that holds
the anycast address and can be secured with a security header.

This keeps the anycast address out of the source address field.
And that will minimize the impact of unicast RPF checks stopping
the packets.

Now, this is still a very rough idea, but an anycast address option
may well help address many of the issues that Itojun pointed out in
his anycast analysis draft.  Of course, there is still a lot of work
to do, issues to iron out, code to write...

Regards,
Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 May 2002 16:04:01 +0200 (CEST)

Brian,

> issues raised by Itojun's anycast analysis draft be addressed.

I wonder if it would also be useful to add a "anycast binding protocol" to
the above list.
Certain protocols (be it TCP or DNS resolvers wanting to verify the IP
addresses in the responses) coupled with the technical issues (such as
path MTU discovery) and operational issues (such as how to debug) of
using anycast as a source address, I think would benefit from such
a protocol with reasonable security.

By "reasonable security" I mean that for delivering packets to an anycast
address we depend on the routing system not being compromised (and your item #2
above needs to preserve that). Wouldn't it be possible to use this trust in
the routing system to get a binding between an anycast address and one current
member of that address one would ask.

I think the MIPv6 Binding Update has reuseable elements for such a protocol.

But this is still a bit of a solution looking for a problem.

   Erik

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 May 2002 10:40:52 -0400

Erik,

> a protocol with reasonable security.

Actually, I will have to let on to a little secret.  I have been
looking at an option for anycast that looks strikingly similar to the
Home Address option in MIPv6.  The idea is that a server responding to
an anycast query will put the anycast address in this option and its
own unicast address in the source address field.  The option can be
protected with an AH header, thus allowing the sender to authenticate
that the response is coming from a member of the anycast group.

This option would also allow for TCP connections to an anycast address.
A TCP implementation could allow a connection to an anycast address
as long as it recognizes the option containing the anycast address.

The option would also preserve the use of RPF filtering on source
addresses.

> But this is still a bit of a solution looking for a problem.

I believe that there may be useful pieces in MIP that could help
make anycast work.  I freely admit that the anycast option is based
on the home address option from MIP.  I just hope that I can spend
some time on the topic soon.

Brian

---

From: [email-masked]
Date: Wed, 15 May 2002 04:13:38 +0900

>The option would also preserve the use of RPF filtering on source

	it was already discussed in the past, and dropped after deering's
	comment - source address limitation rule must be applied to
	the content of home address option, so we can't put multicast
	address or anycast address into home address optioon (based on RFC2460).
	pls see anycast-analysis draft.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 May 2002 15:16:37 -0400

>         pls see anycast-analysis draft.

But, this isn't the home address option.  The characteristics will be
different.  Like I said, I am still working on the details.

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 May 2002 21:41:27 +0200 (CEST)

> that the response is coming from a member of the anycast group.

This approach to security assumes a globally deployed PKI.
So you seem to be on a path that't been tried before without success.

I think in order to avoid this dependency one should think about basing
the security on the routing system functioning. Thus if there
is a response saying that Unicast X is a member of Anycast A,
then there would be a return routability check to both X and A,
and only a node which would receive both the packet sent to A and X 
would be able to respond with the needed "cookies". This sounds like
about 2 roundtrips to securely find the mapping from A to X.

We could chat more off-line if you'd like.

   Erik