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

[Dan Wing <[e-mail]>]

On Jul 8, 2013, at 7:56 AM, Jose Saldana <[e-mail]> wrote:

> So it seems that the possibility of a document about Security & TCM-TF might
> be interesting. What about adding a sentence in the Charter (re-chartering
> paragraph), talking about that possibility?
> 
> ....
> 9. If other interesting features are identified, the group would re-charter
> and include them, e.g., a 
> mechanism for a multiplexer to discover a de-multiplexer, and vice versa; a
> mechanism to select an 
> optimal multiplexer and a de-multiplexer when there are more than one
> muxer/de-muxer for a flow; 
> dynamically applying TCMTF: a higher entity in charge of deciding when and
> where, applying or not 
> TCMTF, and what kind of TCMTF, and what multiplexing period. Additional
> methods for estimating delay 
> would also be required; *security issues related to TCM-TF, and methods for
> securing TCM optimized flows.*


This text detracts from the charter, because it lists only one reason we might re-charter to broaden the WG's scope.  There are lots of reasons we might re-charter to broaden the WG's scope, of course.  So I don't think this text is really saying anything that needs to be said.

-d


> ....
> 
> Jose
> 
>> -----Mensaje original-----
>> De: [e-mail] [mailto:[e-mail]] En nombre de
>> Diego R. Lopez
>> Enviado el: lunes, 08 de julio de 2013 11:59
>> Para: <[e-mail]>
>> CC: <[e-mail]>; Muthu Arul Mozhi Perumal (mperumal); jsalazar; Dan
>> Wing
>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>> 
>> Hi,
>> 
>> When talking about security, we should not forget two different aspects:
>> 
>> 1) Applying TCMTF to enhance (or provide a better support to) security
>> network services, like IPsec or VPNs
>> 
>> 2) Securing the application of TCMTF itself
>> 
>> As far as I can tell, most of the discussion so far has been on the first
> aspect.
>> This could be outlined as an use case, and further discussed in a separate
>> document if required, oriented towards "Applying TCMTF in secure
>> environments" or the like
>> 
>> Regarding the second issue, I tried to make a few points some time ago:
>> 
>> 8<---
>> 
>>> We can consider different security contexts for different tunnels,
> according
>> to some policy agreed by both end-points at a given tunnel. The security
>> contexts would define encryption, authentication, or both. We'd have to go
>> into more detail to evaluate potential savings, but I have the feeling
> they
>> could be worth considering.
>>> 
>>> The point is that if we go for these different security contexts, we
> must
>> consider how they can be established by mutual authentication of the
> tunnel
>> end-points, and this opens additional issues regarding configuration and
>> crypto material exchange, as well as the possibility of user-initiated
>> authentication by means of protocols like OAuth.
>>> 
>>> I'd keep this in the list of the "soon-to-open" issues, focusing on the
> three
>> main docs we have been discussing so far.
>> 
>> 8<---
>> 
>> I had the intention to elaborate them a little more, but other matters
> pre-
>> empted this :-( My take is that some reflections on this should be
> included in
>> the "Security Considerations" section of the framework document, and a
>> further document on this be considered in a further stage.
>> 
>> Be goode,
>> 
>> On 8 Jul 2013, at 09:28 , Jose Saldana wrote:
>> 
>>> Hi, Muthu, Dan, Jose Luis.
>>> 
>>> It seems that we have identified some cases in which different security
>> options are possible. The question here is:
>>> 
>>> Can this be issued in the TCMTF main draft (TCMTF Reference Model)?
>>> 
>>> Or do you think a TCMTF-security document would be interesting?
>>> 
>>> Jose
>>> 
>>> -----Mensaje original-----
>>> De: jsalazar [mailto:[e-mail]] Enviado el: jueves, 04 de
>>> julio de 2013 19:36
>>> Para: [e-mail]
>>> Asunto: RE: [tcmtf] Answers to possible questions in the BOF
>>> 
>>> 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,
>>>> tunnel------> 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
>>> 
>>> _______________________________________________
>>> tcmtf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcmtf
>> 
>> 
>> --
>> "Esta vez no fallaremos, Doctor Infierno"
>> 
>> Dr Diego R. Lopez
>> Telefonica I+D
>> http://people.tid.es/diego.lopez/
>> 
>> e-mail: [e-mail]
>> Tel:    [phone]
>> Mobile: [phone]
>> -----------------------------------------
>> 
>> 
>> ________________________________
>> 
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>> _______________________________________________
>> tcmtf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcmtf
>