One document matched: draft-blanchet-mif-problem-statement-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="info" ipr="full3978" docName="draft-blanchet-mif-problem-statement-00.txt">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title>Multiple Interfaces Problem Statement</title>
    <author initials="M." surname="Blanchet" fullname="Marc Blanchet">
      <organization>Viagenie</organization>
      <address>
    <postal>
      <street>2600 boul. Laurier, suite 625</street>
      <city>Quebec</city>
      <region>QC</region>
      <code>G1V 4W1</code>
      <country>Canada</country>
    </postal>
    <email>Marc.Blanchet@viagenie.ca</email>
    <uri>http://www.viagenie.ca</uri>
  </address>
    </author>
    <date month="December" year="2008"/>
    <abstract>
      <t>A multi-homed host receives node configuration information from each of its access
        networks. Some configuration objects are global to the node, some are local to the interface. 
        Various issues arise when multiple configuration objects that are global to the node are 
        received on the many interfaces the multi-homed host has. This document describes these issues.
        </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>A multi-homed host has multiple network interfaces (physical and/or virtual). For example,
        a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or
        multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and
        smartphones typically have multiple access network interfaces. </t>

      <t>In this document, the multi-homed host does not forward any packet between its interfaces.
        Therefore forwarding devices are out of scope of this document.</t>

      <t>A multi-homed host receives node configuration information from each of its access
        networks, through various mechanims such as DHCPv4 <xref target="RFC2131"/>, DHCPv6 <xref
          target="RFC3315"/>, PPP <xref target="RFC1661"/> and IPv6 Router Advertisements <xref
          target="RFC4861"/>. Some received configuration objects are specific to an interface such
        as the IP address and the link prefix. Others are typically considered by implementations
        as being global to the node, such as the routing information (default gateway), DNS servers IP
        addresses and address selection policies. </t>

      <t>When the received node-scoped configuration objects have different values from each access
        network, such as different DNS servers IP addresses, different default gateways or different
        address selection policies, the node has to decide which it will use or how it will merge them. A document
        discusses (TBD: reference MRW doc) how some current implementations manage these cases.</t>

      <t>Several issues regarding how the node-scoped configuration objects are used 
        in a multi-homed node environment have been
        raised. The following sections describe the issues regarding DNS, routing and address
        selection policy. </t>
    </section>
    <section title="Split DNS">
      <t> A multi-homed host may have one of its interfaces facing a DNS service which resolves
        private names and addresses, as stated in <xref
          target="I-D.savolainen-6man-fqdn-based-if-selection"/>. This split DNS may occur when
        a VPN connection to an enterprise network is setup or in a service provider's network for
        subscribers-only services. These private names and addresses are only relevant to a specific
        interface. Therefore the traffic related to these names and addresses has to go through the
        right interface. However, a typical IP stack does not maintain a binding of the origin of
        the DNS name resolution with its routing table. Therefore the trafic might go 
        to the wrong interface and never reach the destination.</t>
    </section>
    <section title="Routing">
      <t> A multi-homed host may have multiple routes to a destination. However, by default, it does
        not have any hint concerning which interface would be the best to use for that destination. For
        example, as discussed in <xref target="I-D.savolainen-6man-fqdn-based-if-selection"/>
        and <xref target="I-D.hui-ip-multiple-connections-ps"/>, a service provider might want
        to influence the routing table of the host connecting to its network. (TBD: expand)</t>
      <t>A host usually has a node-scoped routing table. Therefore, when a multi-homed host is
        connected to multiple networks and each service provider wants to influence the
        routing table of the host, then conflicts might arise from the multiple routing information
        being pushed to the host. </t>
      <t>A user on such multi-homed host might want a local policy to influence which interface will
        be used based on various conditions. </t>
      <t>On a multi-homed host, some source addresses are not valid if used on some interfaces. For
        example, an RFC1918 source address might be appropriate on the VPN interface but not on the
        public interface of the multi-homed host. If the source address is not chosen appropriately,
        then sent packets might be filtered in the path if source address filtering is in place and
        reply packets might never come back to the source. </t>
    </section>
    <section title="Address Selection Policy">
      <t>An address selection policy <xref target="RFC3484"/> is used to choose the right source and
        destination address for a new connection. It is implemented globally in the node IP stack. </t>
      <t>As discussed in <xref target="RFC4291"/>, a multi-homed host with IPv4 and IPv6 connectivity
        might need to receive an update of its default address selection policy. However, that
        policy is only valid within the context of the interface it received it from. Each network
        on which the node is connected might have a different address policy to push to the
        connecting nodes" The received policies might be conflicting. There is currently no standard
        mechanism to determine what should be the behavior of the stack in such case. </t>
    </section>
    <section title="Summary">
      <t>A multi-homed host receives node configuration information from each of its access
        networks. Some configuration objects are global to the node, some are local to the interface. 
        Various issues arise when multiple configuration objects that are global to the node are 
      received on the many interfaces the multi-homed host has. Therefore, there is a need to define 
      the appropriate behavior of an IP stack and possibly define protocols to manage these cases.</t>
    </section>
    <section title="Security Considerations">
      <t>The problems discussed in this document have direct security implications, since the
        packets that are sent on the wrong interface might be leaking some confidential information.
        Moreover, the undetermined behavior of IP stacks in the multi-homed context bring additional
        threats where an interface on a multi-homed host might be used to conduct attacks targeted
        to the networks connected by the other interfaces.</t>
    </section>
    <section title="IANA Considerations">
      <t>This document has no actions for IANA.</t>
    </section>
    <section title="Authors">
      <t>TBD</t>
    </section>
    <section title="Acknowledgements">
      <t>NAMES have provided input and suggestions to this document.</t>
    </section>
    <section title="Discussion home for this draft">
      <t>This document is intended to define the problem space discussed in the mif@ietf.org mailing list.</t>
    </section>
  </middle>
  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.2131" ?>
      <?rfc include="reference.RFC.3315" ?>
      <?rfc include="reference.RFC.1661" ?>
      <?rfc include="reference.RFC.4861" ?>
      <?rfc include="reference.I-D.savolainen-6man-fqdn-based-if-selection" ?>
      <?rfc include="reference.I-D.hui-ip-multiple-connections-ps" ?>
      <?rfc include="reference.RFC.4291" ?>
      <?rfc include="reference.RFC.3484" ?>
      <!-- RFC4477, mrw -->
    </references>
  </back>
</rfc>