grow: draft-ietf-grow-anycast-pre04

[Joe Abley <[e-mail]>]

Hi all,

We missed the final I-D cut-off by about three hours, by my  
calculations (doh!). However, in the interests of keeping those  
interested in sync with progress, the document we intend to submit as  
-04 is attached.

Some recap of this document's history:

  + the document that completed grow wglc was -02.

  + after some spelling/wordsmithing advice from our AD, we made some  
minor edits and submitted -03 for further IESG consideration.

  + the current working document (to be submitted as -04 in due  
course, per above) attached includes additional changes resulting  
from Secdir and Gen-ART reviews.

Since the changes since -03 are a little more than typographic  
(there's a new section 4.9, for example) we will be asking the grow  
chair to perform an additional last-call on the changes between -02  
and -04, once -04 is available.


Joe


--- draft-ietf-grow-anycast-02.txt     2006-06-27 18:10:06.000000000  
-0400
+++ draft-ietf-grow-anycast-04.txt     2006-06-27 18:09:47.000000000  
-0400
@@ -2,14 +2,14 @@
Network Working Group                                           J. Abley
-Internet-Draft                                                        
ISC
-Expires: April 4, 2006                                      K.  
Lindqvist
+Internet-Draft                                            Afilias  
Canada
+Expires: December 29, 2006                                  K.  
Lindqvist
                                                  Netnod Internet  
Exchange
-                                                            October  
2005
+                                                           June 27,  
2006
                       Operation of Anycast Services
-                       draft-ietf-grow-anycast-02
+                     draft-ietf-grow-anycast-pre04
Status of this Memo
@@ -34,11 +34,11 @@
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
-   This Internet-Draft will expire on April 4, 2006.
+   This Internet-Draft will expire on December 29, 2006.
Copyright Notice
-   Copyright (C) The Internet Society (2005).
+   Copyright (C) The Internet Society (2006).
Abstract
@@ -82,6 +82,7 @@
         4.8.1.  Multiple Covering Prefixes
         4.8.2.  Pessimistic Withdrawal
         4.8.3.  Intra-Node Interior Connectivity
+     4.9.  Node Identification by Clients
     5.  Service Management
       5.1.  Monitoring
     6.  Security Considerations
@@ -90,7 +91,7 @@
       6.3.  Service Hijacking
     7.  Protocol Considerations
     8.  IANA Considerations
-   9.  Acknowlegements
+   9.  Acknowledgements
     10. References
       10.1. Normative References
       10.2. Informative References
@@ -108,6 +109,9 @@
     of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC- 
TN-
     2004-1].
+   The techniques and considerations described in this document  
apply to
+   services reachable over both IPv4 and IPv6.
+
     Anycast has in recent years become increasingly popular for adding
     redundancy to DNS servers to complement the redundancy which the  
DNS
     architecture itself already provides.  Several root DNS server
@@ -125,14 +129,16 @@
     introduces some pitfalls for operation of services.  For example,
     monitoring the availability of the service becomes more difficult;
     the observed availability changes according to the location of the
-   client within the network, and the client catchment of individual
-   anycast nodes is neither static, nor reliably deterministic.
+   client within the network, and the population of clients using
+   individual anycast nodes is neither static, nor reliably
+   deterministic.
     This document will describe the use of anycast for both local scope
     distribution of services using an Interior Gateway Protocol  
(IGP) and
-   global distribution using BGP [RFC1771].  Many of the issues for
-   monitoring and data synchronisation are common to both, but
-   deployment issues differ substantially.
+   global distribution using the Border Gateway Protocol (BGP)
+   [RFC4271].  Many of the issues for monitoring and data
+   synchronisation are common to both, but deployment issues differ
+   substantially.
2.  Terminology
@@ -148,13 +154,18 @@
     Anycast Node: an internally-connected collection of hosts and  
routers
        which together provide service for an anycast Service  
Address.  An
        Anycast Node might be as simple as a single host  
participating in
-      a routing protocol with adjacent routers, or it might include a
+      a routing system with adjacent routers, or it might include a
        number of hosts connected in some more elaborate fashion; in
        either case, to the routing system across which the service is
        being anycast, each Anycast Node presents a unique path to the
        Service Address.  The entire anycast system for the service
        consists of two or more separate Anycast Nodes.
+   Catchment: in physical geography, an area drained by a river, also
+      known as a drainage basin.  By analogy, as used in this document,
+      the topological region of a network within which packets directed
+      at an anycast address are routed to one particular node.
+
     Local-Scope Anycast: reachability information for the anycast  
Service
        Address is propagated through a routing system in such a way  
that
        a particular anycast node is only visible to a subset of the  
whole
@@ -178,9 +189,12 @@
     Anycast is the name given to the practice of making a Service  
Address
     available to a routing system at Anycast Nodes in two or more
-   discrete locations.  The service provided by each node is consistent
-   regardless of the particular node chosen by the routing system to
-   handle a particular request.
+   discrete locations.  The service provided by each node is generally
+   consistent regardless of the particular node chosen by the routing
+   system to handle a particular request (although some services may
+   benefit from deliberate differences in the behaviours of individual
+   nodes, in order to facilitate locality-specific behaviour; see
+   Section 4.6).
     For services distributed using anycast, there is no inherent
     requirement for referrals to other servers or name-based service
@@ -206,7 +220,7 @@
     The scale of the routing system through which a service is anycast
     can vary from a small Interior Gateway Protocol (IGP) connecting a
     small handful of components, to the Border Gateway Protocol (BGP)
-   [RFC1771] connecting the global Internet, depending on the nature of
+   [RFC4271] connecting the global Internet, depending on the nature of
     the service distribution that is required.
3.2.  Goals
@@ -222,17 +236,17 @@
         localising damage to single anycast nodes;
     3.  Constraint of distributed denial of service attacks or flash
-       crowds to local regions around anycast nodes (perhaps  
restricting
-       query traffic to local peering links, rather than paid transit
-       circuits);
+       crowds to local regions around anycast nodes.  Anycast
+       distribution of a service provides the opportunity for  
traffic to
+       be handled closer to its source, perhaps using high-performance
+       peering links rather than oversubscribed, paid transit circuits;
-   4.  To provide additional information to help locate location of
-       traffic sources in the case of attack (or query) traffic which
+   4.  To provide additional information to help identify the location
+       of traffic sources in the case of attack (or query) traffic  
which
         incorporates spoofed source addresses.  This information is
         derived from the property of anycast service distribution that
-       the the selection of the Anycast Node used to service a
-       particular query may be related to the topological source of the
-       request.
+       the selection of the Anycast Node used to service a particular
+       query may be related to the topological source of the request.
     5.  Improvement of query response time, by reducing the network
         distance between client and server with the provision of a  
local
@@ -266,13 +280,13 @@
     Some services have very short transaction times, and may even be
     carried out using a single packet request and a single packet reply
-   in some cases (e.g.  DNS transactions over UDP transport).  Other
-   services involve far longer-lived transactions (e.g. bulk file
-   downloads and audio-visual media streaming).
-
-   Some anycast deployments have very predictable routing systems,  
which
-   can remain stable for long periods of time (e.g. anycast within an
-   well-managed and topologically-simple IGP, where node selection
+   (e.g.  DNS transactions over UDP transport).  Other services involve
+   far longer-lived transactions (e.g. bulk file downloads and audio-
+   visual media streaming).
+
+   Services may be anycast within very predictable routing systems,
+   which can remain stable for long periods of time (e.g. anycast  
within
+   a well-managed and topologically-simple IGP, where node selection
     changes only occur as a response to node failures).  Other
     deployments have far less predictable characteristics (see
     Section 4.4.7).
@@ -298,9 +312,9 @@
        ISP's network, one Anycast Node per site.
     o  A root DNS server service might be distributed throughout the
-      Internet with nodes located in regions with poor external
-      connectivity, to ensure that the DNS functions adequately within
-      the region during times of external network failure.
+      Internet; Anycast Nodes could be located in regions with poor
+      external connectivity to ensure that the DNS functions adequately
+      within the region during times of external network failure.
     o  An FTP mirror service might include local nodes located at
        exchange points, so that ISPs connected to that exchange point
@@ -345,18 +359,18 @@
     distribution (see Section 4.1).
     An IGP will generally have no inherent restriction on the length of
-   prefix that can be introduced to it.  There may well therefore be no
-   need to construct a covering prefix for particular Service  
Addresses;
-   host routes corresponding to the Service Address can instead be
-   introduced to the routing system.  See Section 4.4.2 for more
-   discussion of the requirement for a covering prefix.
+   prefix that can be introduced to it.  In this case there is no need
+   to construct a covering prefix for particular Service Addresses;  
host
+   routes corresponding to the Service Address can instead be  
introduced
+   to the routing system.  See Section 4.4.2 for more discussion of the
+   requirement for a covering prefix.
     IGPs often feature little or no aggregation of routes, partly  
due to
     algorithmic complexities in supporting aggregation.  There is  
little
-   motivation for aggregation in many networks' IGPs in any case, since
-   the amount of routing information carried in the IGP is small enough
-   that scaling concerns in routers do not arise.  For discussion of
-   aggregation risks in other routing systems, see Section 4.4.8.
+   motivation for aggregation in many networks' IGPs in many cases,
+   since the amount of routing information carried in the IGP is small
+   enough that scaling concerns in routers do not arise.  For  
discussion
+   of aggregation risks in other routing systems, see Section 4.4.8.
     By reducing the scope of the IGP to just the hosts providing  
service
     (together with one or more gateway routers) this technique can be
@@ -401,9 +415,9 @@
     Where a routing advertisement from a node corresponds to two or  
more
     Service Addresses, it may not be appropriate to trigger a route
     withdrawal due to the non-availability of a single service.   
Another
-   approach is to route requests for the service which is down at one
-   Anycast Node to a different Anycast Node at which the service is up.
-   This approach is discussed in Section 4.8.
+   approach in the case where the service is down at one Anycast  
Node is
+   to route requests to a different Anycast Node where the service is
+   working normally.  This approach is discussed in Section 4.8.
     Rapid advertisement/withdrawal oscillations can cause operational
     problems, and nodes should be configured such that rapid  
oscillations
@@ -435,7 +449,7 @@
     Where multiple Service Addresses are covered by the same covering
     route, there is no longer a tight coupling between the  
advertisement
     of that route and the individual services associated with the  
covered
-   host routes.  The resulting impact on signaling availability of
+   host routes.  The resulting impact on signalling availability of
     individual services is discussed in Section 4.4.1 and Section 4.8.
4.4.3.  Equal-Cost Paths
@@ -484,9 +498,9 @@
         where the paths converge to a single exit as they leave the AS,
         should cause no node selection problems;
-   3.  PPLB across links to different neighbour ASes where where the
-       neighbour ASes have selected different nodes for a particular
-       anycast destination will, in general, cause request packets  
to be
+   3.  PPLB across links to different neighbour ASes where the  
neighbour
+       ASes have selected different nodes for a particular anycast
+       destination will, in general, cause request packets to be
         distributed across multiple anycast nodes.  This will have the
         effect that the anycast service is unavailable to clients
         downstream of the router performing PPLB.
@@ -516,10 +530,12 @@
     from the instability.
     Some implementations of flap dampening penalise oscillating
-   advertisements based on the observed AS_PATH, and not on the NLRI.
-   For this reason, network instability which leads to route flapping
-   from a single anycast node ought not to cause advertisements from
-   other nodes (which have different AS_PATH attributes) to be  
dampened.
+   advertisements based on the observed AS_PATH, and not on Network
+   Layer Reachability Information (NLRI; see [RFC4271]).  For this
+   reason, network instability which leads to route flapping from a
+   single anycast node will not generally cause advertisements from
+   other nodes (which have different AS_PATH attributes) to be dampened
+   by these implementations.
     To limit the opportunity of such implementations to penalise
     advertisements originating from different Anycast Nodes in response
@@ -527,7 +543,7 @@
     arrange that the AS_PATH attributes on routes from different nodes
     are as diverse as possible.  For example, Anycast Nodes should use
     the same origin AS for their advertisements, but might have  
different
-   upstream ASs.
+   upstream ASes.
     Where different implementations of flap dampening are prevalent,
     individual nodes' instability may result in stable nodes becoming
@@ -535,11 +551,11 @@
     1.  Judicious deployment of Local Nodes in combination with
         especially stable Global Nodes (with high inter-AS path splay,
-       redundant hardware, power, etc) may help limit oscillation
+       redundant hardware, power, etc.) may help limit oscillation
         problems to the Local Nodes' limited regions of influence;
     2.  Aggressive flap-dampening of the service prefix close to the
-       origin (e.g. within an Anycast Node, or in adjcacent ASes of  
each
+       origin (e.g. within an Anycast Node, or in adjacent ASes of each
         Anycast Node) may also help reduce the opportunity of remote  
ASes
         to see oscillations at all.
@@ -596,8 +612,8 @@
     Advertising reachability to Service Addresses from Local Nodes  
should
     ideally be made using a routing policy that require presence of
-   explicit attributes for propagation, rather than reling on implicit
-   (default) policy.  Inadvertant propagation of a route beyond its
+   explicit attributes for propagation, rather than relying on implicit
+   (default) policy.  Inadvertent propagation of a route beyond its
     intended horizon can result in capacity problems for Local Nodes
     which might degrade service performance network-wide.
@@ -644,7 +660,7 @@
     Both of these issues can be mitigated to some extent by the use  
of a
     single covering prefix to accommodate multiple Service  
Addresses, as
-   described in Section 4.8.  This implies a decoupling of the route
+   described in Section 4.8.  This implies a de-coupling of the route
     advertisement from individual service availability (see
     Section 4.4.1), however, with attendant risks to the stability  
of the
     service as a whole (see Section 4.7).
@@ -669,7 +685,7 @@
     might be provided by originating the covering 24-bit prefix.
     For an IPv4-numbered service deployed within a private network, a
-   locally-unused [RFC1918] address might be chosen, and rechability to
+   locally-unused [RFC1918] address might be chosen, and  
reachability to
     that address might be signalled using a (32-bit) host route.
     For IPv6-numbered services, Anycast Addresses are not scoped
@@ -677,7 +693,7 @@
     for IPv4 with respect to address suitability follow for IPv6.  Note
     that historical prohibitions on anycast distribution of services  
over
     IPv6 have been removed from the IPv6 addressing specification in
-   [I-D.ietf-ipv6-addr-arch-v4].
+   [RFC4291].
4.6.  Data Synchronisation
@@ -724,9 +740,17 @@
     The chance of cascading failure due to a software defect in an
     operating system or server can be reduced in many cases by  
deploying
     nodes running different implementations of operating system, server
-   software, routing protocol software, etc, such that a defect which
+   software, routing protocol software, etc., such that a defect which
     appears in a single component does not affect the whole system.
+   It should be noted that these approaches to increase node autonomy
+   are, to varying degrees, contrary to the practical goals of making a
+   deployed service straightforward to operate.  A service which is
+   over-complex is more likely to suffer from operator error than a
+   service which is more straightforward to run.  Careful consideration
+   should be given to all of these aspects so that an appropriate
+   balance may be found.
+
4.8.  Multi-Service Nodes
     For a service distributed across a routing system where covering
@@ -756,7 +780,7 @@
4.8.2.  Pessimistic Withdrawal
     Multiple Service Addresses are chosen such that they are covered  
by a
-   single prefix.  Advertisement and withdrawl of the single covering
+   single prefix.  Advertisement and withdrawal of the single covering
     prefix is coupled to the availability of all associated  
services; if
     any individual service becomes unavailable, the covering prefix is
     withdrawn.
@@ -793,6 +817,31 @@
     of individual nodes; the IGP in which all nodes participate can be
     viewed as a single point of failure.
+4.9.  Node Identification by Clients
+
+   From time to time, all clients of deployed services experience
+   problems, and those problems require diagnosis.  A service
+   distributed using anycast imposes an additional variable on the
+   diagnostic process over a simple, unicast service -- the particular
+   anycast node which is handling a client's request.
+
+   In some cases, common network-level diagnostic tools such as
+   traceroute may be sufficient to identify the node being used by a
+   client.  However, the use of such tools may be beyond the abilities
+   of users at the client side of a transaction, and in any case  
network
+   conditions at the time of the problem may change by the time such
+   tools are exercised.
+
+   Troubleshooting problems with anycast services is greatly  
facilitated
+   if mechanisms to determine the identity of a node are designed in to
+   the protocol.  Examples of such mechanisms include the NSID  
option in
+   DNS [I-D.ietf-dnsext-nsid] and the common inclusion of hostname
+   information in SMTP servers' initial greeting at session initiation
+   [RFC2821].
+
+   Provision of such in-band mechanisms for node identification is
+   strongly recommended for services to be distributed using anycast.
+
5.  Service Management
@@ -820,10 +869,11 @@
     Service [2] and the University of Oregon Route Views Project [3].
     Monitoring the health of the component devices in an Anycast
-   deployment of a service (hosts, routers, etc) is straightforward,  
and
-   can be achieved using the same tools and techniques commonly used to
-   manage other network-connected infrastructure, without the  
additional
-   complexity involved in monitoring Anycast service addresses.
+   deployment of a service (hosts, routers, etc.) is straightforward,
+   and can be achieved using the same tools and techniques commonly  
used
+   to manage other network-connected infrastructure, without the
+   additional complexity involved in monitoring Anycast service
+   addresses.
6.  Security Considerations
@@ -864,11 +914,21 @@
     might be difficult to detect by clients or by the operator of the
     service.
-   The risk of service hijacking by manipulation of the routing sytem
+   The risk of service hijacking by manipulation of the routing system
     exists regardless of whether a service is distributed using  
anycast.
     However, the fact that legitimate Anycast Nodes are observable  
in the
     routing system may make it more difficult to detect rogue nodes.
+   Many protocols which incorporate authentication or integrity
+   protection provide those features in a robust fashion, e.g. using
+   periodic re-authentication within a single session, or integrity
+   protection at either the channel (e.g.  [RFC2845], [RFC2487]) or
+   message (e.g.  [RFC4033], [RFC2311]) levels.  Protocols which are
+   less robust may be more vulnerable to session hijacking.  Given the
+   greater opportunity for undetected session hijack with anycast
+   services, the use of robust protocols is recommended for anycast
+   services that require authentication or integrity protection.
+
7.  Protocol Considerations
@@ -880,7 +940,7 @@
     This document requests no action from IANA.
-9.  Acknowlegements
+9.  Acknowledgements
     The authors gratefully acknowledge the contributions from various
     participants of the grow working group, and in particular Geoff
@@ -894,17 +954,9 @@
10.1.  Normative References
-   [I-D.ietf-ipv6-addr-arch-v4]
-              Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in
-              progress), May 2005.
-
     [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
                RFC 793, September 1981.
-   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
-              (BGP-4)", RFC 1771, March 1995.
-
     [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,  
G., and
                E. Lear, "Address Allocation for Private Internets",
                BCP 5, RFC 1918, February 1996.
@@ -922,6 +974,12 @@
     [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for  
Multihomed
                Networks", BCP 84, RFC 3704, March 2004.
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
10.2.  Informative References
     [Allman2000]
@@ -935,6 +993,10 @@
                January 2004, <http://www.caida.org/outreach/papers/ 
2003/
                nlanr/nlanr_overview.pdf>.
+   [I-D.ietf-dnsext-nsid]
+              Austein, R., "DNS Name Server Identifier Option (NSID)",
+              draft-ietf-dnsext-nsid-02 (work in progress), June 2006.
+
     [ISC-TN-2003-1]
                Abley, J., "Hierarchical Anycast for Global Service
                Distribution", March 2003,
@@ -959,9 +1021,27 @@
                Defeating Denial of Service Attacks which employ IP  
Source
                Address Spoofing", RFC 2267, January 1998.
+   [RFC2311]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
+              L. Repka, "S/MIME Version 2 Message Specification",
+              RFC 2311, March 1998.
+
+   [RFC2487]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              TLS", RFC 2487, January 1999.
+
+   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for  
DNS
+              (TSIG)", RFC 2845, May 2000.
+
     [RFC3765]  Huston, G., "NOPEER Community for Border Gateway  
Protocol
                (BGP) Route Scope Control", RFC 3765, April 2004.
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
URIs
     [1]  <http://dnsmon.ripe.net/>
@@ -975,6 +1055,8 @@
     This section should be removed before publication.
+   Intended category: BCP.
+
     draft-kurtis-anycast-bcp-00:  Initial draft.  Discussed at IETF  
61 in
        the grow meeting and adopted as a working group document shortly
        afterwards.
@@ -988,23 +1070,33 @@
        hosts removed; minor sentence re-casting and related jiggery-
        pokery.  This revision published for discussion at IETF 63.
-   draft-ietf-grow-anycast-02:  Normative reference to [I-D.ietf-ipv6-
-      addr-arch-v4] added (in the RFC editor's queue at the time of
-      writing; reference should be updated to an RFC number when
-      available).  Added commentary on per-packet load balancing.
+   draft-ietf-grow-anycast-02:  Normative reference to
+      draft-ietf-ipv6-addr-arch-v4" added (in the RFC editor's queue at
+      the time of writing; reference should be updated to an RFC number
+      when available).  Added commentary on per-packet load balancing.
+
+   draft-ietf-grow-anycast-03:  Editorial changes and language clean-up
+      at the request of the IESG.
+
+   draftt-ietf-grow-anycast-04:  Replaced reference to RFC1771 with a
+      reference to RFC4271.  Replaced reference to
+      draft-ietf-ipv6-addr-arch-v4 with a reference to RFC 4291.
+      Changed author address for Abley.  Wordsmithing in response to
+      Gen-ART review by Sharon Chrisholm and Secdir review by Rob
+      Austein.  Added Section 4.9 at the suggestion of Rob Austein.
Authors' Addresses
     Joe Abley
-   Internet Systems Consortium, Inc.
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   Phone: [phone]
-   Email: [e-mail]
-   URI:   http://www.isc.org/
+   Afilias Canada, Corp.
+   204 - 4141 Yonge Street
+   Toronto, ON  M2P 2A8
+   Canada
+
+   Phone: [phone]
+   Email: [e-mail]
+   URI:   http://afilias.info/
     Kurt Erik Lindqvist
@@ -1055,7 +1147,7 @@
Copyright Statement
-   Copyright (C) The Internet Society (2005).  This document is subject
+   Copyright (C) The Internet Society (2006).  This document is subject
     to the rights, licenses and restrictions contained in BCP 78, and
     except as set forth therein, the authors retain all their rights.