Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Owen DeLong <[e-mail]>]

> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
>>> 
>>> What you refer to has to do with the diode-firewall thing (which is a side effect in nat, and that folks are replicating in ipv6 by deploying a diode firewall where you currently have a nat box). Obviously, if your policy is that you don't want incoming connections, and i have the same policy then, unfortunately, we have to talk to a third party.
>> Nope. It is much easier to establish a connection across a diode firewall than to establish one across a NAT. In the former case, all the endpoints need to do is send each other packets at about the same time. In the latter, they need to implement NAT traversal via relays.
> 
> 
> It is only 'slightly' easier... Because guessing the TCP sequence number of the other party... Well good luck :-)

With a diode firewall, you don’t have to guess. Most diode firewalls don’t look at TCP sequence numbers actively. They look only at the L3 and L4 identifiers to determine state.
Some look at SYN bits and toss SYN packets going in the wrong direction, but most just look for an ACK bit.

Nonetheless, it’s also much easier because a diode firewall can easily be given an exception to permit a particular flow or the initiation of a class of flows to a particular protected host or set of hosts.

In the case of a NAT, however (more specifically a NAPT), it is not possible to program multiple port 80 terminations to land on different hosts behind the NAT.

In short, without NAT, flows which are desired can be permitted. With NAT, this is much more difficult and in many cases, impossible.

I retain my perspective that one of the worst and most ultimate forms of layering violation is for a forwarding system not residing on either of the end-hosts in a session to impersonate an end-host and mutilate unexpected portions of the datagram in flight.

Owen