Subject: Re: [sunset4] draft-ietf-sunset4-nat64-port-allocation

From: GangChen <[email-masked]>
Date: Wed, 7 Oct 2015 06:09:59 +0800

Hello Alberto,

Thank you for reading the draft.

2015-09-25 4:15 GMT+08:00, Alberto Leiva <[email-masked]>:
> Hi
>
> Regarding Port Randomization:
>
> Isn't hole punching worth mentioning? This being an analysis and all. Hole
> punching is like the "good" counterpart of TCP port-guessing attacks.
>
> It seems port randomization trumps simultaneous open of TCP connections
> (RFC 6146 pp. 28-30), so a random NAT64 could even forego or optional-out
> their implementation to avoid its complexity and performance hit (due to
> packet storage).
>
> See
> http://ietf.10.n7.nabble.com/Re-Last-Call-draft-ietf-behave-v6v4-xlate-stateful-Stateful-NAT64-Network-Address-and-Protocol
> and
> http://ietf.10.n7.nabble.com/Re-Review-of-the-NAT64-document-td214997.html

I read the discussion you pointed. It seems talking about the impacts
of TCP state change on NAT64 to the hole punching (I miss the first
link, it's invalid any more).
It would be helpful if you could elaborate more on the relation of
port randomization and hole punching. Not sure I understand correctly,
it seems you prefer using port randomization to facilitate the hole
punching process, in which simultaneous open of TCP connections are
involved. I may not able to figure out the hole punching process based
on port randomization, since port randomization may not can help users
to discover their exact NAT mapping, also it can't replace outbound
signalling, e.g., SIP.

Would be good to hear you more;)

> ------------------------------
>
> Also a small nitpick, feel free to ignore:
>
> Isn't the terminology a bit all over the place?
>
> In particular
>
>> Stateless NAT is performed in compliance with [RFC6145].
>> (...) Thus the NAT64 can directly extract the address and has
>> no need to record mapping states.
>
> What do you mean? RFC 6145 is SIIT, which to my knowledge is only
> informally (and some might say incorrectly) known as "Stateless NAT64"
> (much less "Stateless NAT")... even if it's "network address translating".
>
> Through the whole document the word "NAT64" is used where "IPv4/IPv6
> translation" would perhaps be more appropriate.
>
> "Stateless NAT64" doesn't exist. Or, at the very least, it isn't defined in
> any standards that I have seen.

RFC7599 may help.
There are several statements, like "It builds on existing stateless
NAT64 techniques specified in [RFC6145],...", "A stateless NAT64
function [RFC6145] is extended to allow stateless mapping of IPv4 ..."

BRs

Gang

> Alberto

---

From: Tore Anderson <[email-masked]>
Date: Wed, 7 Oct 2015 07:20:41 +0200

* GangChen <[email-masked]>

> > "Stateless NAT64" doesn't exist. Or, at the very least, it isn't
> > defined in any standards that I have seen.
> 
> RFC7599 may help.

Except for the fact that the RFC7599 is making a false claim here:
RFC6145 simply *doesn't* specify «stateless NAT64». As it happens, the
only occurrence of the string «NAT64» in RFC6145 is in a reference to
RFC6146.

Any draft could potentially include a sentence such as «blah blah, the
Awesome Buttered Bacon Protocol (ABBP) [RFC2460], blah blah». But that
doesn't mean that «ABBP» from that point on becomes a officially correct
name for the protocol specified in RFC2460, now does it?

Tore

---

From: GangChen <[email-masked]>
Date: Wed, 7 Oct 2015 22:33:11 +0800

> name for the protocol specified in RFC2460, now does it?

Completely agree.

In another words, RFC2460 may not represent the entire ABBP, but that
is first thing people flash in their mind, isn't it?

I guess it's similar meaning as for "STATELESS NAT64". There is the
term. Best reference serving the concept is RFC6145. that's it.

BTW, the statement in this draft is "Stateless NAT is performed in
compliance with [RFC6145]." So, that is not saying RFC6145 is complete
stateless nat, but the algorithm for stateless processing is referring
the RFC6145.

BRs
Gang

---

From: Alberto Leiva <[email-masked]>
Date: Wed, 7 Oct 2015 17:46:46 -0500

You did figure hole punching out. It's my opinion on it that confuses you.

> Not sure I understand correctly,
> punching process,

It's the other way around. I do prefer port randomization, but it makes
hole punching difficult.

As an implementor, I prefer port randomization over hole punching. But
that's just my opinion.

> in which simultaneous open of TCP connections are
> involved.

People achieves hole punching by doing a Simultaneous Open. So, for the
purposes of this discussion, think hole punching = Simultaneous Open.

> I may not able to figure out the hole punching process based

Exactly. Since the port mapping is random, people can't predict it, so they
can't punch the hole.

Therefore, a random NAT64 has little reason to have to deal with the
trouble of supporting Simultaneous Open.

"Dealing with the trouble of supporting Simultaneous Open" is having to
store a fake session and a packet for 6 seconds, and then answer an ICMP
error to the packet.

> term. Best reference serving the concept is RFC6145. that's it.

Fine. But really; what is the problem with using official terms in a formal
document?

---

From: GangChen <[email-masked]>
Date: Sat, 10 Oct 2015 01:19:01 +0800

> Exactly. Since the port mapping is random, people can't predict it, so they

People could use behave technologies (stun/turn/ice) to determine the
port mapping even there is random port mapping. I can't see the
difficulty. Am I missing something?