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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

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