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

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

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.

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.
-----

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
> >