Subject: [BEHAVE] Not having our NAT66 cake but still eat it

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 10:37:58 +0100

Perhaps we can adopt a different approach regarding NAT66.

Rather than specify how to do it in the least harmful way we can think  
of, what if we define what applications can expect from the network?  
Then application writers know what to expect, and if vendors want to  
buil IPv6 NATs, they know what they can get away with without breaking  
well written applications.

This would allow us to move forward and provide some containment for  
possible NAT66 sprawl without explicitly implicitly condoing NAT66 by  
specifying NAT66. (It of course still implicitly implicitly condones  
NAT66...)

Obviously this can only work if we at least concede that applications  
don't assume that what they see as their source address is what their  
correspondents see. However, there may be non-NAT reasons why this  
isn't the case. For instance, some applications may run on clusters of  
hosts and may want to provide references to another instance of the  
application, or there may be a proxy in the middle.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 12:48:43 +0100

On 26 nov 2008, at 10:37, Iljitsch van Beijnum wrote:

> what if we define what applications can expect from the network?  
> buil IPv6 NATs, they know what they can get away with without  
> breaking well written applications.

Just realized: the internet is an _unreliable_ datagram network.  
(Well, more like an unreliable session network these days.) The whole  
point is to work around the unreliabilities that come up when you  
interconnect private networks. (Within a private network you can build  
in as much reliability as you want/need.)

So the whole idea of a network with unimpeded end-to-end reachability  
is fundamentally incompatible with the internet.

Then again, we shouldn't make things harder for ourselves than  
necessary.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 13:08:03 -0500

Iljitsch van Beijnum wrote:
>> what if we define what applications can expect from the network? Then
>> application writers know what to expect, and if vendors want to buil
>> IPv6 NATs, they know what they can get away with without breaking well
>> written applications.
> 
> Just realized: the internet is an _unreliable_ datagram network. (Well,
> more like an unreliable session network these days.) The whole point is
> to work around the unreliabilities that come up when you interconnect
> private networks. (Within a private network you can build in as much
> reliability as you want/need.)
> 
> So the whole idea of a network with unimpeded end-to-end reachability is
> fundamentally incompatible with the internet.

The "classic" internet architecture doesn't assume perfect reliability.
 The network is expected to occasionally drop datagrams or to duplicate
them.

One could argue that the network is occasionally (rarely) allowed to
corrupt packets, and that's what IP and transport level checksums are
for.  However, it's also supposed to make a "best effort" to deliver
them intact.

NATs don't do that.  From the point of view of the endpoints, NATs block
a high percentage of datagrams in one direction and consistently corrupt
datagrams going in the other direction.

Of course the NATs try to "corrupt" datagrams in a "useful" way (for a
less-than-universal idea of useful) and to avoid disrupting applications
(for a narrow view of applications).  But because NATs necessarily lack
a complete view of the network and a complete understanding of how
applications use the network, autonomous NATs will always be disruptive.

The point here is that the kind of damage NATs do to traffic isn't
compatible with the kinds of unreliability that were expected from the
network in the classic internet architecture.

Actually I'd claim that one of the fundamental, but unstated, underlying
assumptions of the Internet architecture is that all hosts are assigned
unique addresses, and that the mapping from addresses to hosts is
consistent throughout the entire network.  Many aspects of the
architecture depend on this - routing and TCP sequence number
negotiation being two that come to mind immediately.

(Note that this is mostly an academic/historical discussion at this
point, as we certainly don't have a "classic" internet architecture in
place today for IPv4 and there's scant chance of having it for IPv6.)

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Nov 2008 10:20:41 +1300

> of, what if we define what applications can expect from the network?

As in:

The network will make a best effort to deliver your packet unchanged,
except that it might unpredictably change the source address, the
destination address, the DSCP and ECN bits, and (if you're lucky)
correctly recalculate the transport checksum. Oh, and if it's IPv4,
it might change the port numbers. Oh, and if one end is IPv4 and the
other end is IPv6, it will change the entire IP header. Also in that
case, DNS may give you a fake response. Caveat emptor.

I find it hard to imagine we can define this with precision *except*
by doing what BEHAVE is trying to do.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Nov 2008 13:54:02 -0800

> by doing what BEHAVE is trying to do.

I think you forgot to mention that the network might also  
unpredictably [but-- again, if you're lucky-- *consistently*] change  
all those same header fields when they're embedded in ICMP errors.

In fact, it's also possible that the network might transparently  
intercept your TCP 3-way handshakes, making it appear like the  
destination endpoint is negotiating its connection with you, when in  
fact, it's a middlebox interposing itself in the process for policy  
enforcement purposes.

If you really really want to prevent the network from interfering like  
this, then you have an alternative: IPsec.  I suspect it will turn out  
that the force that ultimately drives the adoption of IPsec will not  
be security considerations but simply efforts aimed at achieving  
network transparency.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering