[e2e] j'accuse NFV

[Detlef Bosau]

Am 04.05.2015 um 14:27 schrieb Djamel Sadok:
> Hi,
>
> May be we could also give the end user flow the possibility to say that it
> does not want to have its data packets processed by any NFV or even black
> list some NFVs (types of functions) on the path. Would this be possible to
> achieve? would it render NFV ineffective? can both NFV and Not NFV (bypass
> it) on given flows live together?
>
> Djamel
>

I think, we're going to mix up layers here.

Let me again refer to the TR "Beyond the Radio: Illuminating
the Higher Layers of Mobile Networks". And quote the following:

> These middleboxes can poten-
> tially modify user traffic, compromise user privacy
> by injecting HTTP headers that uniquely identify
> users or reveal their location,

????

To my understanding, HTTP traffic uses TCP. (And let me well note, that
this is some kind of implementation, we could well put this in question.)

To my understanding, TCP privacy is a PURE end to end issue. Nothing else.

When there is even the remote possibility that a TCP flow's privacy can
be compromised by a middle box, this is either the case in Germany,
where the
de-mail project suffers exactly from this problem
http://en.wikipedia.org/wiki/De-Mail
or something is made fundamentally wrong.

In his talk "A new way to look on networking" in 2006, Van Jacobson
mentioned three requirements for any kind of message switching system,
which he thinks to be inevitable.

Any message must be 1) idempotent, 2) its integrity must be ensured, 3)
its authenticity must be ensured.

As long as these three requirements are fulfilled, anything else MUST
NOT matter.

(And yes, I could add the "J'accuse TCP" piece here which Lloyd
requested, because TCP datagrams AREN'T idempotent. The content is - but
the protocol handling isn't, think about DUP ACKs.)


Detlef