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

[jltornos <[e-mail]>]

Hi all,

in the proposed scenario there are two options for establishing a secure 
communication:
- first, a user uses a tunnel from the beginning to the end of the 
communication, one SA (security association).
- second, we use two different tunnels, i.e. two different SAs.

In both scenarios the users have to trust TCM nodes, but in the first 
one the users have to share the security parameters (at least the secret 
key) with the TCM nodes, while in the second scenario the users directly 
establish a secure communication with the TCM nodes.

José Luis


El 2013-07-11 10:44, Jose Saldana escribió:
> Muthu,
> 
> So you have a "bunch" of IPsec flows, and you
> - decrypt each flow
> - compress headers
> - multiplex packets
> - put the multiplexed bundle in an IPsec packet, using a new IPsec 
> tunnel
> 
> So you would have three phases:
> - separate IPsec tunnels for each flows
> - a single IPsec tunnel for the TCM flow
> - separate IPsec tunnels in the end
> 
> Origin 1
> Origin 2     <----20 secured flows --------> TCM-IO <------1 
> tunnel------>
> TCM-EO <-------- 20 secured flows----> destination 1, 2, 20
> ...
> Origin 20
> 
> But I think this raises a question: the TCM ingress optimizer must be 
> able
> to decrypt all the flows. This implies that it knows the keys and it is
> trusted by the communication ends.
> 
> This would be the most efficient solution, but you would need some
> requirements:
> 
> - trust the TCM optimizer
> - processing capacity for decrypt-compress-multiplex-encrypt
> 
> Is this what you are thinking?
> 
> Jose
> 
> -----Mensaje original-----
> De: Muthu Arul Mozhi Perumal (mperumal) [mailto:[e-mail]]
> Enviado el: miércoles, 10 de julio de 2013 12:00
> Para: [e-mail]; Dan Wing (dwing)
> CC: [e-mail]; [e-mail]
> Asunto: RE: [tcmtf] Answers to possible questions in the BOF
> 
> Hi Jose,
> 
> |But in this case you have two security layers: the original flows use
> |IPsec, and you are adding another IPsec tunnel including all the
> compressed
> ones.
> 
> No, just one IPSec tunnel. The idea is to compress the headers of all
> packets
> that need to go over the same IPSec tunnel, multiplex them and give it 
> to
> the
> IPSec layer. The IPSec layer would add the IP/ESP header and send it 
> over
> the IPSec tunnel. The next header field in ESP would tell there is a 
> mux
> header following it, and the mux header can be used to demux the packet
> after IPSec decryption.
> 
> Muthu
> 
> |-----Original Message-----
> |From: Jose Saldana [mailto:[e-mail]]
> |Sent: Wednesday, July 10, 2013 1:21 PM
> |To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing)
> |Cc: [e-mail]; [e-mail]
> |Subject: RE: [tcmtf] Answers to possible questions in the BOF
> |
> |Muthu,
> |
> |But in this case you have two security layers: the original flows use
> |IPsec, and you are adding another IPsec tunnel including all the
> compressed
> ones.
> |Am I right? Would this be necessary?
> |
> |Jose
> |
> |> -----Mensaje original-----
> |> De: [e-mail] [mailto:[e-mail]] En nombre
> |> de Muthu Arul Mozhi Perumal (mperumal) Enviado el: jueves, 04 de
> |> julio de 2013 15:42
> |> Para: Dan Wing (dwing)
> |> CC: [e-mail]; [e-mail]; [e-mail]
> |> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
> |>
> |> |My read of it was:  apply ROHC at the endpoint ("inner headers") 
> and
> |> |then do IPsec.  That is, compress and then encrypt.
> |>
> |> Right, Dan. I was thinking the (inner) headers of the packets going
> |> over
> |the
> |> same IPSec tunnel could first be compressed, multiplex, then
> |> encrypted and sent over that tunnel:
> |>
> |> --------------------------------------------
> |> |outer IP hdr| ESP | MUX | ROHCoIPsec|Data1|
> |> |            |     | hdr |   hdr1    |     |
> |> --------------------------------------------
> |>                           ----------------------
> |>                           | ROHCoIPsec | Data2 |
> |>                           |    hdr2    |       |
> |>                           ----------------------
> |>                           -------------------------------------
> |>                           | ROHCoIPsec |  Data3  | ESP   | ESP|
> |>                           |    hdr3    |         |Trailer| ICV|
> |>                           -------------------------------------
> |>                     <-----------Encrypted-------->
> |>
> |> Muthu
> |>
> |> |-----Original Message-----
> |> |From: Dan Wing (dwing)
> |> |Sent: Thursday, July 04, 2013 12:26 AM
> |> |To: Muthu Arul Mozhi Perumal (mperumal)
> |> |Cc: [e-mail]; [e-mail]; [e-mail]
> |> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
> |> |
> |> |
> |> |On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal)
> |> <[e-mail]> wrote:
> |> |
> |> |> |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).
> |> |>
> |> |> Actually, RFC5856 describes how ROHC can be used over IPSec
> |> (ROHCoIPsec).
> |> |
> |> |My read of it was:  apply ROHC at the endpoint ("inner headers") 
> and
> |> |then do IPsec.  That is, compress and then encrypt.
> |> |
> |> |-d
> |> |
> |> |
> |> |> Combining it with multiplexing the entire packets could provide
> |> |> significant reduction in the header
> |> |overhead, especially for IPv6, I think.
> |> |>
> |> |> Muthu
> |> |>
> |> |> |-----Original Message-----
> |> |> |From: [e-mail] [mailto:[e-mail]] On
> |> |> |Behalf Of Dan Wing (dwing)
> |> |> |Sent: Monday, July 01, 2013 10:25 PM
> |> |> |To: [e-mail]
> |> |> |Cc: [e-mail]; [e-mail]
> |> |> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
> |> |> |
> |> |> |
> |> |> |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-2
> |> |> |58082.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