Re: [tcmtf] Answers to possible questions in the BOF

["Jose Saldana" <[e-mail]>]

Hi, Jose Luis. Good point.

Regarding security, we could establish this classification:

1- Adding security to TCM: I have a number of non-secured flows traveling through a “dangerous” network segment (perhaps a tunnel between appliances connecting remote offices of a company), and I want not only traffic optimization but also security. In this case, I can simply use IPsec on the tunnel.


2- Using TCM for optimizing already secured communications: I have a bunch of already secured flows. Which is the best way for tunneling, compressing and multiplexing them?

Two subcases:

2a- I can use TCM normally, but not only compress IP, TCP or UDP headers, but also security headers using a header compression method. Some possibilities for compressing security headers:

- ROHCoIPsec, RFC5856 (http://tools.ietf.org/html/rfc5856)
- RFC5225 http://tools.ietf.org/html/rfc5225


2b- But I can save more bandwidth if the TCM-ingress optimizer (TCM-IO) is able to:
- rebuild the packets to their native form
- TCM-optimize them 
- put them into a single security tunnel

I have three phases (let's suppose I have 20 communications):

Origin 1
Origin 2     <----20 secured flows --------> TCM-IO <------1 tunnel------> TCM-EO <-------- 20 secured flows----> destination 1, 2, 20
...
Origin 20

I have an advantage: In the shared network path, I use a single tunnel instead of 20 different tunnels.

But I have some additional requirements: I need processing capacity in the TCM optimizers, and the endpoints should trust them.


Is this classification correct? Any other options? Any other requirements? It is time for "security experts".

Jose

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> jsalazar
> Enviado el: lunes, 01 de julio de 2013 20:50
> Para: [e-mail]
> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
> 
> Hi all:
> Mmmmmmm. Since I see tcm-tf as a service, I can design the service with
> added security features that the type of communication is requiring. I think
> we have to be clear what we are expressing when we are talking about
> secure tcm-tf: Ensuring the service tcm-tf or applying the tcm-tf service for
> secure communications.
> The first possibility is not a great technological sophistication and the second
> one might consider the first one as a possible additional service. Therefore,
> every time we use the term "secure tcm-tf" should think the second option,
> for generality.
> On the other hand, we must also keep in mind that whenever users employ
> secure tcm-tf, they must trust the service fully and consider delegating the
> use of their keys (including private ones) to tcm-tf.
> 
> Regards.
> 
> JL
> 
> "I see them falling out the skies like eagles
> All mirrored glass and shattered egos"
> 
> Simple Minds.
> 
> El 2013-07-01 18:55, Dan Wing escribió:
> > On Jun 28, 2013, at 1:57 AM, [e-mail] wrote:
> >
> > Hi all,
> >
> > Few days ago Julian talked about TCM-TF's security and now I've read in
> > the link included by Dan, saying that the gain obtained when
> > multiplexing Ipsec-encrypted packets is 20-to-1. We have been looking
> > for more information about this issue and thinking about a way to
> > reduce the needed  bandwidth in IPsec flows.
> >
> > The main idea is to find a way to change the authentication of the
> > individual packets and merge all of them in a unique authentication.
> > Thus, instead of using 20 IPsec tunnels, we would have a single tunnel
> > including 20 flows. Is this something similar than how Cisco gets the
> > improvement?
> >
> > We would not be able to change IPsec any more than we could change
> > TCP, so I would not look at how to change IPsec authentication.
> >
> > However, if there are a bunch of IPsec packets sharing a common path,
> > I could see them being successfully multiplexed into one larger packet
> > at one tunnel endpoint and then de-multiplexed at the other tunnel
> > endpoint.  This can provide a packet per second reduction.  I don't
> > think there are enough bytes in an IPsec header to bother trying to do
> > IPsec header compression (SPI and sequence number are only 64 bits).
> >
> > -d
> >
> >
> >
> > José Luis
> >
> >
> >
> > Dan Wing <[e-mail]> ha escrito:
> >
> >
> > On Jun 26, 2013, at 3:49 AM, Jose Saldana <[e-mail]> wrote:
> >
> > Question 4: Is TCM-TF interesting for the Industry? Should the IETF
> > standardize this?
> >
> > Answer:
> >
> > 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP  traffic.
> > So if RFC4170 was interesting, why not updating it?
> >
> > 2) TCM-TF can be useful in order to save bandwidth in many cases:
> >
> > - Aggregation network of *network operators*: We are saving  bandwidth
> > by optimizing and putting together traffic flows. Is this  interesting
> > for a network operator? What about overprovisioning?  The idea is that
> > there are places and moments in which a number of  flows based on small
> > packets are in the same place and at the same  moment. Then, TCM-TF can
> > be applied in order to provide  flexibility. We are not optimizing the
> > overall Internet traffic, we  are optimizing specific flows with very
> > tight delay requirements,  which network operators have to take care of
> > in a special way.
> > www.huawei.com/ilink/en/download/HW_193034
> >
> > - *End to end* optimization: Nowadays, many appliances are used to
> > connect remote offices of the same company (creating a VPN). So if  a
> > tunnel exists, why not optimizing this traffic when possible? We  would
> > save bandwidth in the access network, where it can be scarce.
> >
> > - Wireless and satellite scenarios.
> >
> > "Cisco adds IP multiplexing to mobile satellite package", April  2012,
> > http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-
> 258082.html
> >
> >
> >
> >
> >
> > Any other thoughts? Any other scenarios in mind? Potential
> > beneficiaries?
> >
> > Some networks, today, use cRTP (RFC2508) on their access links.   This
> > gives bandwidth savings on the access link, but consumes  considerable
> > CPU horsepower on the aggregation router (to perform  cRTP), but
> > provides no bandwidth savings across the network core.   If, instead,
> > the bandwidth could be saved on the access link, across  the core, and
> > on the far-end access link -- all without the CPU  impact on the
> > aggregation router -- it is a considerable win.
> >
> > -d
> >
> >
> >
> >
> >
> > Jose
> >
> > De: [e-mail] [mailto:[e-mail]] En  nombre
> > de Jose Saldana
> > Enviado el: lunes, 24 de junio de 2013 13:00
> > Para: [e-mail]
> > Asunto: [tcmtf] Answers to possible questions in the BOF
> >
> > I would like to start a thread about possible questions people may  ask
> > in the BOF. Obviously, we also need answers, so we should  cooperate.
> >
> > This is different from the "questions to ask in the BOF". This will  be
> > discussed separately.
> >
> > Thanks!
> >
> > Jose
> >
> > _______________________________________________
> > tcmtf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > tcmtf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> 
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf