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

[Dan Wing <[e-mail]>]

On Jul 10, 2013, at 12:50 AM, Jose Saldana <[e-mail]> wrote:

> What about these "security considerations"? (including Gorry's suggestions):
> 
> ------
> The most straightforward option for securing a number of non-secured flows
> sharing a path is by the use of IPsec [IPsec], when TCM using an IP tunnel
> is employed. Instead of adding a security header to the packets of each
> native flow, and then compressing and multiplexing them, a single IPsec
> tunnel can be used in order to secure all the flows together, thus achieving
> a higher efficiency. This use of IPsec protects the packets only within the
> transport network between tunnel ingress and egress and therefore does not
> provide end-to-end authentication or encryption. In some cases , e.g., where
> the end points are trusted, this model may be appropriate.

I was agreeing with you until the example, which suggests endpoint trust is somehow useful/important for using IPsec to protect traffic.  It is not relevant if the endpoints are trusted (botnet traffic is perfectly okay to get put inside an IPsec tunnel); rather, it is relevant to use IPsec if the IPsec-protected path is vulnerable to attack (passive attack [sniffing] or active attack [injection]).

I would just drop that last sentence (the sentence starting with "In some case, ...").

> When a number of already secured flows including ESP [RFC4303] headers are
> optimized by means of TCM, and the addition of further security is not
> necessary, their ESP/IP headers can still be compressed using suitable
> algorithms [RFC5225], in order to improve the efficiency. This header
> compression does not change the end-to-end security model.
> 
> Future versions of this document will consider whether some TCM-TF
> mechanisms could be potentially exploited in order to deploy or amplify DoS
> attacks against network infrastructure.
> -----

Gorry was worried about DoS of TCMTF itself, too.  So change last paragraph to also say "will consider DoS vulnerability of TCM-TF itself" in addition to what you already have about TCMTF being used to create a DoS attack against other stuff.  But, keeping it simpler, how about just saying:  "The resilience of TCM-TF to denial of service, and the use of TCM-TF to deny service to other parts of the network infrastructure, is for future study."

-d


> Do you think the third paragraph should be included in this version? Should
> we wait before talking about that?
> 
> Thanks, Gorry,
> 
> Jose
> 
>> -----Mensaje original-----
>> De: [e-mail] [mailto:[e-mail]]
>> Enviado el: martes, 09 de julio de 2013 12:56
>> Para: [e-mail]
>> CC: 'Diego R. Lopez'; [e-mail]; 'Muthu Arul Mozhi Perumal
>> (mperumal)'; 'jsalazar'; 'Dan Wing'
>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>> 
>> A few comments on the security considerations.
>> 
>> Can you also please add the counter-argument to using IPsec?
>> 
>> - This use of IPsec protects the packets only within the transport network
>> between tunnel ingress and egress and therefore does not provide end-to-
>> end authentication or encryption. In some cases , e.g. where the end
> points
>> are trusted this model may be appropriate.
>> 
>> - On the second point, please clarify:
>> -- which headers are compressed?
>> -- does this change the end-to-end security model (I think not).
>> 
>> I suggest you quote RFCs for the security mechanisms that you discuss.
>> 
>> Finally, you may like to consider DoS attacks against TCMTF. Transport
> groups
>> are usually required to consider whether the mechanisms can be exploited
>> to generate traffic that does not respond to congestion control or can be
>> used to amplify the attack on network infrastructure. If you can comment
> on
>> these that would seem good - I suggest you should note this as future work
>> in later revisions of the draft.
>> 
>> Gorry
>> 
>> 
>>> Hi all,
>>> 
>>> I am finishing the next version of the draft. In the "security
>>> considerations" section in the end. The idea is talking about the two
>>> options (as summarized by Diego):
>>> 
>>> - Securing the application of TCMTF itself
>>> - Applying TCMTF to enhance (or provide a better support to) security
>>> network services, like IPsec or VPNs
>>> 
>>> So I would include these two paragraphs, if you agree:
>>> 
>>> 
>>> The most straightforward option for securing a number of non-secured
>>> flows sharing a path is by the use of IPsec [IPsec], when TCM using an
>>> IP tunnel is employed. Instead of adding a security header to the
>>> packets of each native flow, and then compressing and multiplexing, a
>>> single IPsec tunnel can be used in order to secure all the flows
>>> together, thus achieving a better efficiency.
>>> 
>>> When a number of already secured flows including ESP headers is
>>> optimized by means of TCM, and the addition of further security is not
>>> necessary, their ESP headers can still be compressed using suitable
>>> algorithms, in order to improve the efficiency.
>>> 
>>> 
>>> Any improvements? Any other ideas?
>>> 
>>> 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
>>>>>> tunnel------> 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
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> _______________________________________________
>>> tcmtf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>> 
> 
>