Subject: [RRG] Mitigating the Downsides of NAT'ing

From: Christian Vogt <[email-masked]>
Date: Fri, 21 Mar 2008 17:28:56 +0200

Folks,

the discussion on interworking (subject "Comments on draft-lewis-lisp-
interworking") has shown that both PTRs and NAT'ing have important
shortfalls:  PTRs lack a convincing incentives model, and NAT'ing has
technical issues.  One way of solving the problem is to try and find
an incentives model for PTRs, another would be to mitigate the
technical issues of NAT'ing.  Six/One Router is doing the latter, and
maybe this can provide the right balance between incentives and
technical soundness.  Would be interesting to hear your opinion.

Robin and Brian brought up 3 technical issues with normal NAT'ing:

(1)  Unreachability of hosts behind NAT

(2)  Translation issues (processing complexity, exhaustion of external
      address pool, premature state expiry)

(3)  Loss of end-to-end semantics

Here is how Six/One Router mitigates these issues:

(1)  Hosts reachable at edge and transit addresses

      This requires DNS proxies in upgraded (i.e., Six/One-Router-
      capable) edge networks:  Receiving an A/AAAA query, a proxy
      queries for both edge and transit addresses. The full reply is
      forwarded to Six/One routers (to be used for mapping), but only
      edge addresses are forwarded to the resolver.  There are 3
      options for realizing this (many credits to Stéphane Bortzmeyer):

      (1a)  Both edge and transit addresses are returned in standard
            A/AAAA records, and extra (newly defined) "E/EEEE" records
            indicate which ones are edge addresses.  The DNS proxy
            forwards only the A/AAAA records that include edge
            addresses to the resolver.  This is compatible with DNSSEC
            because forwarded records are unchanged.

      (1b)  Transit addresses are returned in A/AAAA records, edge
            addresses in E/EEEE records.  The DNS proxy converts the
            E/EEEE records into A/AAAA records and forwards them to the
            resolver.  DNSSEC can only be used between the proxy and
            the DNS servers; the resolver must trust the proxy.

      (1c)  Like (1b), but DNSSEC signatures for E/EEEE records are
            computed as if the record type was that of A/AAAA records.
            DNSSEC end-to-end between the DNS servers and the resolver.

      DNS proxies may be configured into hosts as DNS servers, or they
      may be co-located in Six/One routers to intercept DNS queries
      leaving the edge network.  The latter enables hosts to use DNS
      servers outside their edge network.

(2)  1-to-1 NAT'ing whenever possible

      Most of the issues with today's NATs are specific to many-to-1
      translation and absent from 1-to-1 translation.  Address
      translation in Six/One Router can always be 1-to-1.  Only when a
      host in an upgraded edge network communicates with an IPv4-only
      host in a legacy edge network, many-to-1 translation may be more
      desired due to IPv4 address scarcity.

      If two upgraded edge networks communicate, Six/One Router does
      not perform NAT'ing, but rather an equivalent to tunneling.

(3)  Provide reverse-mapping functionality

      A Six/One router has functionality for "inverse" NAT'ing (which
      yields an equivalent to tunneling).  This eliminates the
      disadvantages of NAT'ing when Six/One Router is deployed on both
      sides of a packet exchange.

Six/One Router is certainly not a panacea against the adverse impacts
of NATs.  But it eliminates some of them from day one, and all of them
for an increasing number of packet exchanges on the long run.

- Christian

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 25 Mar 2008 11:12:54 +0100

Hi,

>            because forwarded records are unchanged.

This will actually break the DNSSEC. If I'm correct, signatures are
generated over the whole RRset, and if you only forward a part of the
RRset, the validation will fail.

In other words, this has the same problem as proposal 1b: The proxy can
validate the DNS, but the resolver must trust the proxy.

Matthijs Mekking
[email-masked]
Foundation NLnet Labs

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2008 14:36:49 -0700

Matthijs,

> RRset, the validation will fail.

An RRset is defined (in RFC 2181) to be all records of the same label,  
class, and type.  The E/EEEE records would be of a different type and  
thus would be outside of the A/AAAA RRset over which the signature  
would be generated.  Of course there would be no verifiable binding  
between the two (not sure that matters).

Regards,
-drc

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 27 Mar 2008 15:08:51 +0100

Hi David,

comments in between.

David Conrad wrote:
> thus would be outside of the A/AAAA RRset over which the signature would
> be generated.  

Correct, but this doesn't address my concern. Suppose the resolver
queries for AAAA records. The Six/One proxy will then query the DNS for
AAAA and EEEE records. It receives both RRsets. It checks the signature
for the AAAA RRset and the signature for the EEEE RRset. So far so good.
Now it checks which AAAA record holds the identifier, by comparing the
AAAA set with the EEEE set. It only forwards to the resolver the AAAA
records that holds identifiers, not the AAAA records that holds
locators. The resolver cannot validate the signature for the AAAA set,
since not all AAAA records were provided to him (only the one holding
identifiers).

> Of course there would be no verifiable binding between
> the two (not sure that matters).

I think if you trust the authoritative nameserver, the signatures will
be sufficient.

Regards,

Matthijs Mekking
[email-masked]
Foundation NLnet Labs