[tcmtf] Fwd: RE: Answers to possible questions in the BOF

[jsalazar <[e-mail]>]

-------- Mensaje original --------
Asunto: RE: [tcmtf] Answers to possible questions in the BOF
Fecha: 2013-07-04 19:35
Remitente: jsalazar <[e-mail]>
Destinatario: [e-mail]

Hi all.
With your last question, you have just hit the bullseye. I think the 
classification is correct. Cases 1 and 2a are a good way to keep the 
compromise between security and efficency. However, case 2b gives a step 
beyond and the security is compromised in the interest of efficiency.
In that case, users have to trust in tcmtf manager for managing their 
privacy also. Then, we will leave the tipical Public Key Infraestructure 
(PKI) security architecture and use the Identity Based Encryption (IBE) 
one (http://tools.ietf.org/html/rfc5408).
They are three different scenarios and all of them seem to be very 
interesting, but the last one a bit more.
Regards:

JL

"I see them falling out the skies like eagles
All mirrored glass and shattered egos"

Simple Minds.

El 2013-07-03 17:58, Jose Saldana escribió:
> 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