[afnog] privacy vs caching

[Kofi ANSA AKUFO]

By now everyone knows Andrew operates networks in over 10 countries :)

Seriously regardless of how caching is defined it is currently been done at
various layers and points in the data path.

I quite remember one company - DiViNetworks
<http://bgp.he.net/AS57731#_peers> - which was selling some form of
patented bandwidth optimization (which caching in general addresses -" flag
repititive data patterns to speed up delivery and also optimize bandwidth
utilization) solution which identifies bit patterns or streams instead of
files or web objects. I noticed many ISPs around the globe
<http://bgp.he.net/AS57731#_peers> currently subscribe to their service
especially when they reach 90 -95% of their upstream capacity (usually
their DS3 and STM1 internet transit capacity) to gain extra 50% on
bandwidth. At least that is the selling benefits.

Then again we have good old squid cache boxes of various implemetations
which surprisingly many ISPs still have sitting on their networks.

Our browsers also do have some caching capabilities in built.

Generally caching also helps to mitigate applications sensitive to jitter
as well as latency. It also plays a significant role in the world internet
enabled devices (i.e. smart phones).

Now encryption which we use various methods, SSL included - we all agree is
essential for privacy and data integrity. So my questions are;

Are these two functional requirements mutually exclusive?

Are there currently any caching implementations which do not break
encryption or more to say data integrity?

Cheers

K.



On 22 December 2014 at 14:39, Andrew Alston <Andrew.Alston at liquidtelecom.com
> wrote:

> Personally, I¹d be very unhappy with losing the ability to do end to end
> encryption and having an ISP fake certificates etc.  In my mind, this
> would be a form of mis-representation.
>
> With regards to the latency tradeoff.  I can understand the needs to solve
> the latency problems, though I would ask at what cost when introducing
> these types of solutions.  My experience with caching at an ISP level has
> not been positive.  The benefits in terms of traffic saved were
> questionable at best when considering the cost of the devices, and the
> performance improvement I saw in my testing didn¹t justify the expense.
> I¹d rather spend the money improving the network to drive down the
> latencies.
>
> With the advent of GGC caches, Facebook caches, and large scale CDN
> devices on net and on continent, I¹m just not sure that caching to the
> point of breaking encryption is really worth it.  Especially when in
> Africa, we are busy moving away from the paradigm of 500ms latencies and
> traffic all looping back through Europe, and into an era where real
> bandwidth, decent latencies and proper on-continent peering is a reality.
>
> (With regards to the perspective I speak from for clarity, I¹m resident in
> Kenya and operate networks in South Africa, Zimbabwe, Mozambique, Zambia,
> Tanzania, Kenya, Uganda, Rwanda, Burundi and Somalia)
>
> Just my thoughts.
>
> Andrew Alston
> Group Head of IP Strategy
>
>
> Sameer business Park, Block A, Mombasa Road. Nairobi, Kenya
>
> T: +254 205000000 -  M: +254 733 2222 04 - E:
> andrew.alston at liquidtelecom.com
>
>
>
>
>
>
>
>
> On 12/21/14, 8:54 PM, "Randy Bush" <randy at psg.com> wrote:
>
> >caching is very difficult with end-to-end encryption as the cache does
> >not have the private keys of the server.  the ietf is in a bit of a
> >muddle on this.  should one allow middle-boxes to break the encryption
> >and fake it?
> >
> >so which is more important to you and your customers (think consumers,
> >banks, news sites, ...), end-to-end encryption to ensure privacy, or
> >caching to reduce bandwidth consumption and improve latency?
> >
> >randy
> >
> >_______________________________________________
> >afnog mailing list
> >http://afnog.org/mailman/listinfo/afnog
>
>
> DISCLAIMER:  This email contains proprietary information some or all of
> which may be legally privileged. It is for the intended recipient only. If
> an addressing or transmission error has misdirected this email, please
> notify the author by replying to this email. If you are not the intended
> recipient, you must not use, disclose, copy, print, or rely on this email.
> We cannot accept liability for any statements made which are clearly the
> sender's own and not expressly made on behalf of this company or one of its
> agents.
>
>
> _______________________________________________
> afnog mailing list
> http://afnog.org/mailman/listinfo/afnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://afnog.org/pipermail/afnog/attachments/20141222/e065d290/attachment.html>