Dear IAB (CC to IETF list);
I wrote a position paper for SEMI workshop and it was rejected
with a surprising review comment, all of the point of which
is wrong.
So far, that's life.
The problem, however, is that the review comment are so
surprising that the result of SEMI workshop is very simply
proven (see below) to be "incorrect and incomplete".
So, I'd like to request to do reviewing again with the proof
against the original reviewing process in mind, which may
results in cancellation or rescheduling of the workshop.
The proof does not use any claims done in my paper.
The proof follows.
According to RFC3424 written by IAB:
o Shipping NATs often contain Application Layer Gateways (ALGs)
which attempt to be context-sensitive, depending on the source or
destination port number. The behavior of the ALGs can be hard to
anticipate and these behaviors have not always been documented.
and the end to end argument by Saltzer et. al.:
The function in question can completely
and correctly be implemented only with
the knowledge and help of the application
standing at the end points of the
communication system.
it is impossible for end systems behind an ALG to help the ALG with
their knowledge, because the often-undocumented behavior of the ALG
is not known to the end systems.
So, the only possibility to restore the end to end transparency is:
1) Keep the ALG of NAT as is and, with the cooperation of both ends
(servers and clients), avoid the port numbers contaminated by the
ALG.
or
2) Make the behavior of the ALG known to the end systems behind
the ALG and modify IP stack of the end systems to help the known
behavior of the ALG, which means the NAT box having the unknown
ALG behavior must be replaced or upgraded.
However, in the review comment, it is stated that:
> SRV in particular may work to confound assumptions about ports along
> the path, but many of the port-linked behaviors are under the control
> of the server operators anyway, so it is hart to see how this on its
> own would do much to restore end-to-endness.
which exclude approach 1), and that:
> and (2) replacing NAT boxes and endpoint IP stacks, which
> would seem to limit its incremental deployability;
which excludes approach 2), because CFP of the workshop requires
the incremental deployability.
So, from the review comment, the review committee of SEMI2015
has excluded the possibility to achieve its goal "correctly and
completely".
QED
Thus, proposals not using approaches 1), 2) or both, is proven
to be incorrect and incomplete.
The result of improperly reviewed SEMI2015 will be incorrect
and incomplete.
If you are fine with incorrect and incomplete solutions, why are
you bothered by the incorrectness and incompletness of NAT?
Masataka Ohta
PS
Proposal in my paper is to take approach 1) and the full end
to end transparency is restored for applications over TCP
or UDP (that is, almost all applications), if the middlebox
is UPnP capable.
Replacement of middleboxes is necessary only if the middlebox is
UPnP incapable, middleboxes are improperly nested or transport
protocols other than TCP/UDP are necessary.
Thus, the review comment:
> and (2) replacing NAT boxes and endpoint IP stacks, which
> would seem to limit its incremental deployability;
is simply wrong.
The remaining review comment is:
> E2ENAT also seems to
> require (1) reducing the ability of NAT to reduce address allocation
> pressure
which is also simply wrong, because dynamic E2ENAT is as efficient
as dynamic existing NAT, while static port forwarding on existing
NAT may be "reducing the ability of NAT to reduce address allocation
pressure".