Subject: [rrg] Suggestion of text for the ILNP document

From: Fred Baker <[email-masked]>
Date: Fri, 30 Apr 2010 01:12:05 +0100

There are of course some issues surrounding network prefix translation, which is used in NAT66, GSE, and ILNP. I forwarded this text to Margaret for her to think about in the next NAT66 revision; it or something like it might be worth considering in an ILNP-related document or in the recommendation.

Begin forwarded message:

>    <section anchor="network" title="Network Issues">
>      <t>There are issues in the deployment of networks using Network Prefix
>      Translation technology. These build on concepts raised in <xref
>      target="RFC2993"></xref> and <xref target="RFC3424"></xref> in the IPv4
>      domain, and add specific issues deriving from. These considerations
>      apply to GSE or any GSE-like architecture, including <xref
>      target="I-D.rja-ilnp-dns">ILNP</xref><xref
>      target="I-D.rja-ilnp-icmp"></xref><xref
>      target="I-D.rja-ilnp-intro"></xref><xref
>      target="I-D.rja-ilnp-nonce"></xref>.</t>
> 
>      <t>Three fundamental concerns arise in the use of Network Address
>      Translation as performed in IPv4 networks: <list style="symbols">
>          <t>The translator is obliged to maintain mapping state between
>          address domains,</t>
> 
>          <t>Systems in one domain have no way to know what address to use to
>          access systems in another domain, and</t>
> 
>          <t>The system itself has no such knowledge either.</t>
>        </list></t>
> 
>      <t>Network prefix translation as described in this document, in ILNP,
>      and in other proposals, lacks the issue of maintaining state - apart
>      from configuring the prefixes of the two domains in the translator there
>      is no such state - but the issues of end to end transparency remain in
>      an altered form. Any system that has an address in one domain is
>      reachable from the other, but there is a question of determining what
>      address to use for the purpose. Here, we try to tease apart the
>      issues.</t>
> 
>      <section anchor="mismatch" title="Mismatched Prefix Lengths">
>        <t>The translation algorithm assumes that the two domains have the
>        same prefix length. If the internal domain is using a ULA (which is a
>        /48) and the external domain is using a longer prefix such as a /56,
>        /60, or /64, the translation is undefined. The simplest solution is
>        to, at configuration time, extend the shorter prefix to the length of
>        the longer by appending a fixed bit string such as zeroes.</t>
> 
>        <t>For example, in a network that uses only link-local addresses in
>        the private domain and a provider-allocated /64 in the public domain,
>        the interior side of the translator is configured with FE80::/64 and
>        the external domain is configured with the provider-allocated /64.
>        Similarly, if the internal domain is using a ULA, such as
>        FD12:3456:789A::/48, and the external domain is using a /56 such as
>        2001:db8:1234:5600::/56, the two domains would be configured as
>        FD12:3456:789A:0000::/56 and 2001:db8:1234:5600::/56 respectively, and
>        externally addressable internal subnets would limited to
>        FD12:3456:789A:0000::/56. Note that the other subnets in the ULA are
>        still usable internally, but will not be correctly translated by the
>        translator and so are internal-only.</t>
> 
>        <t>Note that the suggested link-local configuration may not work in
>        practice; since link-local addresses are of local scope, end systems
>        would not generally use them to communicate with a systems whose
>        address has global scope.</t>
>      </section>
> 
>      <section anchor="on-path-attack"
>               title="Issue: Host identification and routing">
>        <t>A characteristic of GSE-style systems in a multi-homed environment
>        is that the response to a request (such as the SYN-ACK in response to
>        a TCP SYN, R1 response to HIP's I1, or IKE_SA_INIT response in IKEv2)
>        may come from a different prefix (locator) than the request went to.
>        There are two possible solutions to the problems that creates: either
>        the session initiator must try different addresses until he gets the
>        response he expects, or (as in <xref
>        target="I-D.rja-ilnp-nonce">ILNP</xref>) an additional value must be
>        included in the exchange to disambiguate possible responses from
>        possible attacks.</t>
> 
>        <t>Mike O'Dell's original note noted that it would be nice if
>        re-routing of multihomed prefixes happened within the duration of an
>        RTT, so that a message that expected a given translator to service it
>        could be re-routed through another without loss. Practically speaking,
>        while this happens, it is not the normal case. Loss resulting from
>        network changes will be picked up by host retransmission, and may
>        change the prefixes (locator) used by the systems as seen by each
>        other.</t>
>      </section>
> 
>      <section anchor="dns" title="DNS Considerations">
>        <t>It is necessary for any system named in DNS to be reachable from
>        any domain that might legally reach it. A system that is only for
>        internal access might only have its ULA in DNS and not external
>        addresses; a system that is reachable by an internal ULA and several
>        provider-allocated prefixes needs to list the ULA and the PA addresses
>        in its DNS record.</t>
> 
>        <t>In networks using traditional Dynamic DNS, a mechanism similar to
>        <xref target="RFC5389">STUN</xref> is necessary to enable systems to
>        determine their "outside" addresses. The one difference is that this
>        is done once or periodically, not on every session. Alternatively, the
>        DNS system itself might identify AAAA records being filed (whether
>        using Dynamic DNS or more static systems) with the internal ULA and
>        generate the corresponding external addresses.</t>
> 
>        <t>In general, the DNS will work more reliably if internally-generated
>        requests for the addresses of internal systems are answered with the
>        internal address and externally-generated requests for the same names
>        get external addresses. If all of the addresses are given on every
>        request, one can expect the source address selection mechanism to
>        prefer the internal address as it is "most similar" to the sender's
>        address, but external requesters have some probability of a failed
>        attempt using the internal address.</t>
>      </section>
> 
>      <section anchor="app" title="Other application considerations">
>        <t>Beyond the issues of DNS, there are many applications that in IPv4
>        networks that make statements to their peers about IP addresses. The
>        vast majority do not, which is the set of systems that work reasonably
>        well through NATs. Examples of some that do include <list
>            style="hanging">
>            <t hangText="HTTP/HTTPS:">HTTP Referrals, using the Referer
>            object, are intended to use names in their URI, but frequently use
>            addresses either to identify the actual system (for debug
>            purposes) or because there is no obvious name. In a GSE
>            environment, referrals should use names.</t>
> 
>            <t hangText="SMTP:">SMTP envelopes, in the "Received" lines,
>            frequently record both the name and address of an interface. In a
>            GSE environment, the name is important.</t>
> 
>            <t hangText="SIP/SDP:">In a SIP session setup, the SDP exchange
>            tells the endpoints each other's addresses. This should go through
>            their proxy, which should be in the same system as or in parallel
>            with the translator.</t>
> 
>            <t hangText="FTP Active Mode:">FTP Active Mode should send a name,
>            not an address.</t>
>          </list></t>
> 
>        <t>In general, the right solution to the issues caused by separated
>        address spaces is to use a proxy at the boundary or to use names, so
>        that the peer is forced to look up the correct address in its
>        domain.</t>
>      </section>
> 
>      <section anchor="PIPA" title="Implications for the larger network">
>        <t>The primary value of using a GSE-like model in the network is that
>        it enables the edge network to behave as if it has a
>        provider-independent and therefore portable address, and for the
>        providers of the Internet to treat addressing as if it were
>        provider-allocated and therefore highly aggregated.</t>
>      </section>
>    </section>
> 
>    <references title="Informative References">
>      <?rfc include="reference.RFC.5389" ?>
> 
>      <?rfc include="reference.RFC.3424" ?>
> 
>      <?rfc include="reference.RFC.2993" ?>
> 
>      <?rfc include="reference.I-D.rja-ilnp-dns"?>
> 
>      <?rfc include="reference.I-D.rja-ilnp-icmp"?>
> 
>      <?rfc include="reference.I-D.rja-ilnp-intro"?>
> 
>      <?rfc include="reference.I-D.rja-ilnp-nonce"?>
> 
>      <?rfc include="reference.I-D.ietf-ipngwg-gseaddr"?>
>    </references>
> 

http://www.ipinc.net/IPv4.GIF

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Apr 2010 08:37:47 -0700

Fred,

> >        provider-allocated and therefore highly aggregated.</t>

As it happens, I very nearly wrote essentially the same
thing in my IRON draft. Edge networks in IRON get to use
PI addressing, while provider networks treat them as if
they were PA.

Thanks - Fred
[email-masked]