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

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

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