Re: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]