Re: [v6ops] Are we competitive?

[Fernando Gont <[e-mail]>]

Hi, Ted,

On 15/8/22 12:03, Ted Lemon wrote:
> I think the thread model for which you’d want to conceal IIDs is that
> you want to prevent callbacks: if a host on the protected network
> makes a connection to a host on the Internet, you don’t want that
> host (or some other host) to be able to attempt to connect back to
> that IP address on a different port looking for a vulnerability.

Yes, that's the obvious case you want to tackle.


> If that’s the case, then you can accomplish this with a firewall. All
> you have to do is default-block incoming SYN packets and incoming UDP
> packets, and you’re done.

Few obvious questions:

1) How do you do this automagically?

2) How do you block "incoming UDP packets" without keeping state?

3) How is the above super different/better than the NAT66 case?

FWIW, we discuss this topic in: 
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-considerations


> This is a lot cheaper than maintaining
> per-connection state. The only problem is that it breaks QUIC. I
> think it might be possible to do the same thing with QUIC, but I
> don’t actually know how the initial handshake works for QUIC, so
> that’s an open question in my mind.

For UDP, the rule of thumb is that you keep state, and if you get a 
packet from the external realm, it's considered an "incoming packet" 
unless you have previously seen a packet with the corresponding (local 
socket, remote socket) in the opposite direction.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494