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

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

Ok, Dan. So the "Security considerations" would be:

    	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.
    	
   	When a number of already secured flows including ESP [ESP] 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.

  	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.

Thanks,

Jose

> -----Mensaje original-----
> De: Dan Wing [mailto:[e-mail]]
> Enviado el: viernes, 12 de julio de 2013 17:53
> Para: [e-mail]
> CC: [e-mail]; 'Diego R. Lopez'; [e-mail]; 'Muthu Arul
> Mozhi Perumal (mperumal)'; 'jsalazar'
> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
> 
> 
> 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
> >>>
> >
> >