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, jltornos@unizar.es 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 <dwing@cisco.com> ha escrito:
> 
> 
> On Jun 26, 2013, at 3:49 AM, Jose Saldana <jsaldana@unizar.es> 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: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En  nombre 
> de Jose Saldana
> Enviado el: lunes, 24 de junio de 2013 13:00
> Para: tcmtf@ietf.org
> 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
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf
> 
> 
> 
> 
> 
> 
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf