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

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Nov 2014 18:43:01 +0900

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Nov 2014 11:22:31 -0500

> with a surprising review comment, all of the point of which

That is because it is a workshop on how the Internet can evolve to
realize the architecture of the stack, not a workshop on how the
architecture of the stack can evolve to address the way people use it.

The only end points that can be fixed end to end on a network are
cryptographic keys and data bound to cryptographic keys. Ports and IP
addresses are ephemera.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 27 Nov 2014 02:27:19 +0900

> architecture of the stack can evolve to address the way people use it.

Your statement has nothing to do with the wrongness of the review
comment of:

   E2ENAT also seems to require (1) reducing the ability of NAT to
   reduce address allocation pressure and (2) replacing NAT boxes and
   endpoint IP stacks, which would seem to limit its incremental
   deployability; as such, the reviewers don't think this proposal
   does much to address the problems raised in the CFP.

> cryptographic keys and data bound to cryptographic keys. Ports and IP

Using cryptographic keys is an interesting solution for SEMI. But, it
requires, to introduce IPSEC or something like that with negotiated SPI
or something like that, cooperation of servers and clients, anyway.

							Masataka Ohta