Internet DRAFT - draft-arifumi-multi6-sas-policy-dist

draft-arifumi-multi6-sas-policy-dist





Internet Engineering Task Force                     Arifumi Matsumoto
Internet-Draft                                      Tomohiro Fujisaki
Expires: April 12, 2005                             Hirotaka Matsuoka
                                                          Jun-ya Kato
                                                          NTT PF Lab.
                                                     October 12, 2004


      Source Address Selection Policy Distribution for Multihoming
              draft-arifumi-multi6-sas-policy-dist-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, we
   certify that any applicable patent or other IPR claims of which we
   are aware have been disclosed, or will be disclosed, and any of which
   we become aware will be disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract

   This document describes a method for the distribution of source
   address selection policy from ISPs to gateway routers for consumers
   and from the gateways to end nodes.  This method is particularly
   effective when a consumer site has multiple address blocks.  Every
   end node is guided by the policy in selecting an appropriate source
   address for each destination address and every gateway is guided by



Arifumi                                                         [Page 1]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


   the policy in forwarding packets to appropriate next-hop ISPs.  This
   makes it possible for an end node to set a connection up without
   being concerned about failures of transfer due to ingress filtering
   by the ISPs, for ISP operators to manage consumers' behavior and
   networking policy, and for consumers to be provided with networks
   that are almost automatically robust and reliable.

1. Introduction

   An IPv6 multihoming site has multiple nodes, each of which is
   assigned multiple IPv6 addresses by up-stream ISPs.  When there are
   multiple up-stream ISPs, the means of selection of the ISP for an
   outgoing packet is currently based on the destination address.  In
   general, however, each packet should have a source address that has
   been allocated by the selected up-stream ISP.  This is because the
   routers of ISPs may be configured to perform ingress filtering with
   the aim of blocking packets that have strange source addresses.

   In this document, we propose a technique that is used both to
   distribute policy information for source address selection at end
   nodes and to establish a method for the forwarding of packets by
   routers.  This enables the control of incoming traffic from customer
   sites by ISPs, the selection of appropriate source addresses by end
   nodes, and the selection of outgoing ISPs in a way that is almost
   certain to produce successful connection setup.


2. Concepts

   In this document, we propose a method by which an ISP can distribute
   source address selection policies to each end node at a customer
   site.  The policy information is particularly helpful to hosts in
   which multihoming is used, since an end node can use the destination
   address to select a source address that leads to a high probability
   of successful setup for the connection.

   An up-stream ISP is expected to use DHCPv6 Prefix Options [3633] to
   delegate a certain portion of the IPv6 address space to its
   subscribers.  We propose a DHCPv6 new option, which contains a per-
   delegating-prefix address-selection policy. By making use of this
   option, an ISP can inform its customers of an address block that can
   be reached through the ISP and of a corresponding source address of
   packets, that is, a source address that must be used to reach the
   given block. This is simply achieved through delegation of the
   delegated source-address prefix and policy by the ISP.

   The gateway router of a customer's site receives the delegated prefix
   and address-selection policy mentioned above from its up-stream ISPs.



Arifumi                                                         [Page 2]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


   The router in turn distributes this information to end nodes at the
   site.  Here, we propose an extension to the ND6 Router Advertisement
   Message [2461] and a DHCPv6 [3315] new option to cover delivery of
   address-selection policy to the end nodes.

   The address-selection policy delivered to an end node is stored in
   the form of a Policy Table as defined in RFC 3484 [3484].

   Once the above series of processes is complete, an end node can
   select an appropriate source address for a given destination address.
   Routing of an outgoing packet to the corresponding up-stream ISP is
   mainly guided by the source address of the packet; this avoids
   blocking of the packet by ingress filtering.

   This mechanism is particularly effective when a site subscribes to an
   ISP or VPN service that provides connectivity to a certain closed
   network as well as acting as an ISP for global network connectivity.
   This is because selecting an appropriate source address for a given
   destination address is crucial in such a network environment.

   This approach gives end nodes an advance measure against connection
   setup failure.  At the same time, an ISP can control incoming traffic
   from customers' sites, and the network managers of customers' sites
   can reflect their networking policy to some extent by configuring
   DHCPv6 or ND6 RA settings on routers. The last but not the least
   significant feature to note here is that this sequence of passing,
   processing, generation, and reflection of policy information can be
   made almost totally automatic from the viewpoint of customers.

   In the context of Multi6 WG activity, IMHO this kind of information
   will be very useful in terms of efficiently and effectively setting
   up connections no matter what modifications have been applied to the
   protocol stacks of end nodes.  Also, this will be very helpful for
   those end nodes that haven't received the protocol-stack
   modifications required for this technique, in other words, to legacy
   nodes.

   This document also serves as a proposal for the Multi6 WG to consider
   a mechanism of the kind described as one element of the component
   class.











Arifumi                                                         [Page 3]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


3. Overview

3.1 Multihome Site with Global-Closed Mixed Connectivity

                  ==============
                  |  Internet  |
                  ==============
                       |
         2001:db8::/32 |         3ffe:1800::/32
                  +----+-+   +-+----+
                  | ISP1 |   | ISP2 | (Closed Network)
                  +----+-+   +-+----+
                       |       |
       2001:db8:a::/48 |       | 3ffe:1800:a::/48
         (DHCP-PD')   ++-------++   (DHCP-PD')
                      | Gateway |
                      +----+----+
                           |  2001:db8:a:1::/64
                           |  3ffe:1800:a:1::/64
                           |        (RA'/DHCP')
                 ------+---+----------
                       |
                     +-+----+ 2001:db8:a:1:[EUI64]
                     | Host | 3ffe:1800:a:1:[EUI64]
                     +------+

                        [Fig. 1]

   Fig. 1 shows a multihome site that subscribes to two ISPs. One ISP
   provides global network connectivity and the other provides
   connectivity to a closed network but not to the Internet. This site
   has one border router, labeled Gateway here, and the router may be
   connected to up-stream ISPs through a physical or logical link, say
   PPPoE or an IPsec Tunnel.

3.1.1 Description of Each Element

   i) ISP -> Gateway

     This figure shows that ISP1 has been allocated 2001:db8::/32 and
     ISP2 has been allocated 3ffe:1800::/32.  Each ISP delegates part of
     its address block, called the "provider aggregatable (PA)" block,
     to this customer site.  Here, ISP1 and ISP2 use DHCP-PD to delegate
     2001:db8:a::/48 and 3ffe:1800:a::/48, respectively.

     In this document, we propose an extension to DHCP-PD, which is
     actually a new DHCP option and called DHCP-PD' here.  DHCP-PD'
     gives DHCP servers (ISPs) functionality for delivering an address-



Arifumi                                                         [Page 4]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


     selection policy in combination with a delegated prefix to a client
     (gateway). In this example, ISP2 includes

             Address               Addr. Sel. Policy
             3ffe:1800:a::/48 ---- 3ffe:1800::/32

     in the PD and address-selection policy options sent to the client.
     This means that the subscribers of ISP2 should use an address from
     the delegated range, that is, 3ffe:1800:a::/48, when communicating
     with 3ffe:1800::/32.

     Selection of an appropriate source address is very important, and
     this is particularly so when one of the subscribing networks is
     closed as in this example.  This is simply because a return packet
     from the closed network can't possibly reach the session-
     originating host if the return packet is destined for an address
     beyond the range available to the closed ISP.

     ISP1 also uses DHCP-PD', in this case to deliver its address-
     selection policy to its customers. As ISP1 provides global network
     connectivity, the PD and policy options will take the following
     form.

             Address                Addr-Sel. Policy
             2001:db8:a::/48 --+--  2001:db8::/32
                               +--  ::/0 (all address)

     This means that ISP1 can provide connectivity to 2001:db8::/32 and
     act as a transit point for any other address (::/0) in the Internet
     as long as the source address is that delegated by ISP1, namely
     2001:db8:a::/48.

     With regard to backward compatibility, a normal DHCP-PD packet,
     which does not carry address-selection policy information of the
     above type, should be deemed to have ::/0 as its policy field.

   ii) Gateway -> Host

     A gateway router receives address-delegation information and
     address-selection policy from up-stream ISPs, in turn delivering
     both to down-stream nodes.  In this document, we propose DHCP new
     option and an extension to RA (Router Advertisement Message). We
     refer to these as DHCP' and RA', respectively.  The gateway router
     combines information given by multiple up-stream ISPs and
     distributes the following information down-stream through DHCP' or
     RA'.





Arifumi                                                         [Page 5]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


                     Address                 Addr. Sel. Policy
             1       2001:db8:a:1::/64  --+-- 2001:db8::/32
                                          +-- ::/0
             2       3ffe:1800:a:1::/64 ----- 3ffe:1800::/32

     This is just the combination of the information from the two up-
     stream elements in the previous section, except that each
     advertising address prefix is 64 bits long.

   iii) Host

     When a host receives an RA' or DHCP' message from the site gateway,
     it configures addresses for each receiving network interface and
     reflects address-selection policy in its RFC3484-based policy
     table.

     In this example, we propose that the policy table should be
     configured as follows, by making use of the Label field defined in
     RFC3484, and the relation between address prefix and address-
     selection policy should be kept in this table.

             Prefix                Pref.   Label
             2001:db8::/32         10      100
             ::/0                  10      100
             2001:db8:a:1::/64     10      100
             3ffe:1800::/32        10      200
             3ffe:1800:a:1::/64    10      200

     When this host sends a packet to, for example, 3ffe:1800:a::100,
     whose longest matching entry in this table is 3ffe:1800::/32, the
     host chooses the address beginning with 3ffe:1800:a:1:: as the
     source address.  The source-address selection algorithm will select
     the longest entry that is a candidate source-address range and has
     the same label as the longest matching address for the destination
     address. In the same way, the source address of a packet destined
     for 2001:db8::/32 or 2002::/16 will be 2001:db8:a:1:[EUI64].

     Preference values are only used in the selection of destination
     addresses.  This document does not include an algorithm for
     determining preference values.

   iv) Gateway

     As well as delivering addresses and policy information to hosts
     through RA' or DHCP', the gateway forwards packets according to
     policy information distributed by up-stream ISPs.  One way of
     implementing such forwarding or routing, called policy routing, is
     based on the source addresses of out-going packets. Policy routing



Arifumi                                                         [Page 6]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


     is illustrated in the table below.

             Src.                     Next Hop
             2001:db8:a:1::/64        ISP1
             3ffe:1800:a:1::/64       ISP2

     In this example, the next-hop is deterministically selected by the
     destination address. So, normal destination-address-based routing
     with the following routing table is sufficient.

             Dst.                     Next Hop
             2001:db8::/32            ISP1
             ::/0                     ISP1
             3ffe:1800::/32           ISP2

3.1.2 Discussion

   The benefits of this scheme are very clear.  Every end node can
   determine which source address should be used and can send packets
   without a risk of failure due to ingress filtering or the limited
   reachability of a closed network.

   What should be discussed from here is the need for and implementation
   of policy enforcement to end nodes and the process of combining
   multiple address-selection policies.  It's so hard to combine two
   policies automatically when a policy coming from an ISP conflicts
   with another ISP's policy.  We may also have to think about combining
   or pruning algorithm to contain too much policy information in one
   packet.






















Arifumi                                                         [Page 7]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


3.2 Host with Multiple Home Addresses and Connectivity to Two Global
   Networks

                  ==================
                  |    Internet    |
                  ==================
                       |       |
         2001:db8::/32 |       | 3ffe:1800::/32
                  +----+-+   +-+----+
                  | ISP1 |   | ISP2 |
                  +----+-+   +-+----+
                       |       |
       2001:db8:a::/48 |       | 3ffe:1800:a::/48
         (DHCP-PD')   ++-------++   (DHCP-PD')
                      | Gateway |
                      +----+----+
                           |  2001:db8:a:1::/64
                           |  3ffe:1800:a:1::/64
                           |        (RA'/DHCP')
                 ------+---+----------
                       |
                     +-+----+ 2001:db8:a:1:[EUI64]
                     | Host | 3ffe:1800:a:1:[EUI64]
                     +------+

                        [Fig. 2]

   Fig. 2 shows a host with multiple home addresses that subscribes to
   two ISPs for connectivity to the Internet.  The manner of address
   delegation and allocation is as described in 3.1.

3.2.1 Description of Each Element

   i) ISP -> Gateway

     The difference between this and the previous example is that ISP2
     provides global network connectivity, so the DHCP-PD' address-
     selection policy option for ISP2 includes an additional entry.

             Address                 Addr. Sel. Policy
             3ffe:1800:a::/48 --+-- 3ffe:1800::/32
                                +---  ::/0

   ii) Gateway -> Host

     As both ISPs provide global network connectivity, the policy for
     address-selection from the gateway router to the end nodes is of
     the form shown below.



Arifumi                                                         [Page 8]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


                     Address                  Addr. Sel. Policy
             1      2001:db8:a:1::/64  --+-- 2001:db8::/32
                                         +-- ::/0
             2      3ffe:1800:a:1::/64 --+-- 3ffe:1800::/32
                                         +--- ::/0

   iii) Host

     Each end node will have the following address-selection policy
     table.

             Prefix.             Pref.     Label
             2001:db8::/32       10        100
             2001:db8:a:1::/64   10        100
             (::/0               10        100)
             3ffe:1800::/32      10        200
             3ffe:1800:a:1::/64  10        200
             (::/0               10        200)

     Note that the end nodes are notified of an address-selection policy
     that includes prefix ::/0 by both ISPs, hence a specific source
     address for ::/0 can't be determined in the Label-Rule judgment
     phase described in RFC3484. So, these entries for prefix ::/0 won't
     actually be stored in the policy table, and this policy table won't
     have any effect on source-address selection for packets that match
     ::/0. The source address in these cases will be determined by
     following rules listed in RFC3484, such as longest match with the
     destination address.

   iv) Gateway

     Unlike the previous example (3.1.1(iv)), normal destination-
     address-based routing doesn't specify a particular next-hop.

             Dst                        Next-Hop
             2001:db8::/32              ISP1
             ::/0                       ISP1
             3ffe:1800::/32             ISP2
             ::/0                       ISP2

     So, source-address-based routing as described in 3.1.1(iv) will be
     effective.


3.2.2 Discussion

   One of the benefits of having an ISP provide address-selection policy
   to its customers is that it can explicitly check incoming packets to



Arifumi                                                         [Page 9]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


   see if it delegated their source addresses.  Delivery of an address-
   selection policy makes the following mechanisms possible.

   - Since end nodes and routers in a multihoming site are given some
     kind of routing information, they can select the route expected to
     be optimal. In the above example, end nodes can communicate with
     servers of the ISPs without any circumvention.

    - Another possible usage of this framework is notification of
     security policy. ISPs commonly apply IP-address-based filtering to
     packets that attempt access to their services, such as POP, SMTP
     and Web content, partly for security reasons and partly as a value-
     added service for their customers.

   IMHO one issue to be discussed is multipath routing. In the second of
   the examples presented above, the router and host have two default
   routes and thus have the potential to apply multipath techniques
   [2991][2992]. To take greater advantage of multihoming, we should
   probably consider using a multipath routing algorithm.


3.3 A Host Directly Connected to Multiple ISPs

                  ==================
                  |    Internet    |
                  ==================
                       |       |
         2001:db8::/32 |       | 3ffe:1800::/32
                       |       |
       2001:db8:a::/48 |       | 3ffe:1800:a::/48
       (DHCP-PD') +----+-+   +-+----+  (DHCP-PD')
                  |  GW1 |   | GW2  |
                  +----+-+   +-+----+
     2001:db8:a:1::/64 |       | 3ffe:1800:a:1::/64
     (RA'/DHCP')       |       |        (RA'/DHCP')
                  -----+-+- -+-+-----
                         |   |
    2001:db8:a:1:[EUI64]++---++ 3ffe:1800:a:1:[EUI64]
                        | Host|
                        +-----+

                        [Fig. 3]

   This example shows an end node directly connected to two ISPs, both
   of which provide global network connectivity. The only difference
   between this case and the case described in 3.2 is that the host
   itself has to take on the role of gateway router, that is, of
   applying routing policy based on source addresses.



Arifumi                                                        [Page 10]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


4. Security Considerations

   With regard to the possibility of traffic abduction through the
   announcement of a bogus policy, this scheme seems to neither lower
   nor raise the security level obtained by the existing base-protocols,
   such as DHCP-PD, DHCP and RA. However, it does raise the possibility
   of a new form of DoS attack on routers and hosts, in which large
   numbers of address-selection policies are generated by different
   source addresses. We will have to discuss this and take precautionary
   measures in designing the protocol specification.


5. Normative References

   [3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
          Configuration Protocol (DHCP) version 6," RFC 3633, Dec. 2003.

   [2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
          for IP Version 6 (IPv6)," RFC 2461, Dec. 1998.

   [3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
          Carney, "Dynamic Host Configuration Protocol for IPv6
          (DHCPv6),"  RFC 3315, Jul. 2003.

   [3484] R. Draves, "Default Address Selection for Internet Protocol
          version 6 (IPv6)," RFC 3484, Feb. 2003.

   [2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and
          Multicast Next-Hop Selection," RFC 2991, Nov. 2000.

   [2992] C. Hopps, "Analysis of an Equal-Cost Multi-Path Algorithm,"
          RFC 2992, Nov. 2000.


Authors' Addresses

   Arifumi Matsumoto
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-3334
   E-Mail: matsumoto.arifumi@lab.ntt.co.jp

   Tomohiro Fujisaki
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho



Arifumi                                                        [Page 11]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-7351
   E-Mail: fujisaki.tomohiro@lab.ntt.co.jp

   Hirotaka Matsuoka
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-4949
   E-Mail: matsuoka.hirotaka@lab.ntt.co.jp

   Jun-ya Kato
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-2939
   E-Mail: kato.junya@lab.ntt.co.jp


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an



Arifumi                                                        [Page 12]

draft-arifumi-multi6-sas-policy-dist-00.txt                 October 2004


   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.









































Arifumi                                                        [Page 13]