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

From: "Jose Saldana" <[email-masked]>
Date: Mon, 1 Jul 2013 11:35:06 +0200

Hi, Dan.

I have been reading the article "Cisco adds IP multiplexing to mobile
satellite package", and I think there is an idea we should stress in the
BOF:

We are not only saving bandwidth but also reducing the amount of pps. In the
satellite scenario a pps reduction can be translated directly to a x20
factor in the number of simultaneous calls to be transmitted.

Thanks,

Jose

De: Dan Wing [mailto:[email-masked]] 
Enviado el: miércoles, 26 de junio de 2013 22:14
Para: [email-masked]
CC: [email-masked]
Asunto: Re: [tcmtf] Answers to possible questions in the BOF

On Jun 26, 2013, at 3:49 AM, Jose Saldana <[email-masked]> 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.

 <http://www.huawei.com/ilink/en/download/HW_193034>
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.ht
ml

 

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: [email-masked] [mailto:[email-masked]] En nombre de Jose
Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: [email-masked]
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
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tcmtf>
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 1 Jul 2013 11:46:58 +0200

Hi, Jose Luis.

Regarding security, we can also think about "Unified threat management"
(http://en.wikipedia.org/wiki/Unified_Threat_Management), an appliance used
for connecting remote offices, creating VPNs.

If we merge this concept with "WAN optimization"
(http://en.wikipedia.org/wiki/WAN_optimization), we can have a device next
to the router, which can use TCM-TF.

Considering that security headers, if a new header has to be added to each
packet, then the obtained savings by multiplexing can be even higher.
Perhaps we could do a preliminary study of the expected (asymptotic)
bandwidth savings which could be obtained on each case:

- IPSec
	- transport mode
	- tunnel mode

	- Authentication header
	- Encrypt header

More options?

Perhaps we could consider 20 packets, and calculate:

Number of bytes for a tunnel including 20 packets / Number of bytes for a 20
tunnels

Would it be very complicated? I am not a security expert...

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]
> Enviado el: viernes, 28 de junio de 2013 10:57
> Para: Dan Wing
> CC: [email-masked]; [email-masked]
> 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?
> 
> José Luis
> 
> 
> 
> Dan Wing <[email-masked]> ha escrito:
> 
> >
> >> 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP
> >> traffic. So if RFC4170 was interesting, why not updating it?
> >>
> >> - 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.
> >> - *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.
> >>
> > http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-
> 258
> > 082.html
> >
> >
> >
> >>
> >>
> > 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: [email-masked] [mailto:[email-masked]] En
> >> nombre de Jose Saldana
> >> 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
> >>
> >> [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Jul 2013 09:48:53 -0700

On Jun 27, 2013, at 2:53 AM, [email-masked] wrote:

> Hi Dan,
>  
> Would it be possible to have more info on this CISCO product?

It just holds onto small packets -- especially TCP ACKs -- until a timer fires or the packet is full.  I was not involved with that project, and I don't work on satellite, but I am told this reduces the overhead of the satellite modem dealing with all the little tiny packets.

>  
> Actually, nowadays satellite technology already implements multiplexing capabilities to better exploit the satellite capacity.
> In this respect it would be interesting to understand the interaction of the CISCO multiplexing-enabled router and the functions already available in satellite terminals.

I don't have that detail.

-d

>  
> Thanks in advance
>  
> Regards,
>  
> Tomaso
>  
> ———————————————————————— 
> Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
> German Aerospace Center 
> Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
> Tomaso de Cola, Ph.D. 
> Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
> http://www.dlr.de/kn/institut/abteilungen/san
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Wednesday, June 26, 2013 10:14 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcmtf] Answers to possible questions in the BOF
>  
>  
> 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?
>  
> - 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.
> - *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.
>  
> "Cisco adds IP multiplexing to mobile satellite package", April 2012, http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.html
>  
>  
> 
> 
>  
>  
> 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: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
> 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
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Jul 2013 09:55:25 -0700

On Jun 28, 2013, at 1:57 AM, [email-masked] 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

>>> This is different from the "questions to ask in the BOF". This will  be discussed separately.
>>> 
>>> Thanks!
>>> 
>>> Jose
>>>

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 1 Jul 2013 18:42:44 +0000

In the space of "more ideas" ...

Internet of Things devices are likely to send a lot of little packets, infrequently.  Some of those things will have time-sensitive information - but a whole lot of those things will send information that is not very time sensitive. For example, consider the sensor reporting the present temperature inside my home  freezer where even 500ms or more delay is acceptable.

With many IoT devices, it can be helpful to aggregate those small not-too-delay-sensitive packets.

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, June 26, 2013 6:49 AM
To: [email-masked]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

Answer:

- 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<http://www.huawei.com/ilink/en/download/HW_193034>

Jose

Thanks!

Jose

---

From: jsalazar <[email-masked]>
Date: Mon, 01 Jul 2013 20:50:20 +0200

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ó:
> 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.
> 
> individual packets and merge all of them in a unique authentication. 
> 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
> 
> 
> 
> 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP  traffic. 
> So if RFC4170 was interesting, why not updating it?
> 
> - 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.
> 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.
> 
> http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.html
> 
> 
> 
> 
> 
> 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
> 
> 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.
>

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 3 Jul 2013 12:44:25 +0200

Question 5: Is there a significant amount of traffic of services based on
small packets? Is it interesting to compress it? Why?

Answer (some ideas):

Although the vast majority of Internet traffic corresponds to big packets
(file transfers, video downloads), this best-effort traffic does not present
tight delay requirements.

However, many of the services using small packets have stringent delay
requirements, so the network has to deliver them faster. And this share of
the traffic is really critical for network operators: if I wait 5 seconds to
watch a video, it is not a problem. However, if my VoIP call or my online
game have a latency of 100ms, it can be a serious problem.

In addition, some of these small-packet services are present on certain
network segments where bandwidth may be scarce (residential access,
aggregation networks, satellite links), or a pps limit exists. In the
context of mobile networks:

- New VoIP services are using data links instead of establishing traditional
voice calls (e.g., viber)

- Online games are being played with tablets and smartphones:
<http://www.juniperresearch.com/viewpressrelease.php?id=534&pr=364>
http://www.juniperresearch.com/viewpressrelease.php?id=534&pr=364

- Internet of Things: many "things" will send small packets with a certain
frequency

- New traffic patterns: "Major changes in traffic characteristics are the
increases in small packets, short connections, signaling and data traffic,
and abnormal traffic. For Universal Mobile Telecommunications System (UTMS)
networks in idle status, all these changes lead to sharp increases on
signaling and other system resource load. They also bring severe threat on
network performance, and affect application data throughput capability and
network profitability in the long run." (Huawei Smartphone Solutions White
Paper).

The mobility of the users has some other implications: The network may
experience a "traffic rush" in certain places or moments (e.g., a sports
event, the World release of a new game), so TCM-TF would provide a certain
degree of flexibility (a tradeoff): I don't have to over-dimension my
network. When a traffic rush is detected, I can get advantage of this
tradeoff, compressing traffic up to 50 or 60%, at the cost of a small added
latency. The service would work a bit more slowly, but it would at least
work.

In addition, if I only "awake" TCM-TF optimization when I have a lot of
traffic, then I will add a really tiny latency, since I will have lots of
packets to multiplex, and in 5ms I may be able to create an MTU-sized
multiplexed packet.

Any other ideas?

Jose

This is different from the "questions to ask in the BOF". This will be
discussed separately.

Thanks!

Jose

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 3 Jul 2013 12:41:34 +0000

Jose .. you say:

"I don't have to over-dimension my network. When a traffic rush is detected, I can get advantage of this tradeoff, compressing traffic up to 50 or 60%, at the cost of a small added latency. The service would work a bit more slowly, but it would at least work."

You may have actually over-stated the cost. For such a rush, many of the http sessions during "the rush" would stall (go into slow-start). For that subset you may have prevented the stall! Thus while most of the sessions may incur the cost of "small added latency" (of ~40ms or less), some of the sessions avoided stalling entirely!

I hate it when a web page tries to fetch 100 things ... and the http get of ONE of those things stalls ... and prevents me from using site as intended. Preventing stalls is a good thing.

Also on the "traffic rush" issue ... TCMTF can be used dynamically to lessen bufferbloat (effectively lowering the amount of buffer used on highly buffered links) on a particular egress link. That is, if you see your egress buffer growing, you might try to compress traffic toward it when you can. That could even lessen the delay for all users at such a sports event (lots of small packets representing updates to game statistics).

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, July 03, 2013 6:44 AM
To: [email-masked]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

Question 5: Is there a significant amount of traffic of services based on small packets? Is it interesting to compress it? Why?

Answer (some ideas):

Although the vast majority of Internet traffic corresponds to big packets (file transfers, video downloads), this best-effort traffic does not present tight delay requirements.

However, many of the services using small packets have stringent delay requirements, so the network has to deliver them faster. And this share of the traffic is really critical for network operators: if I wait 5 seconds to watch a video, it is not a problem. However, if my VoIP call or my online game have a latency of 100ms, it can be a serious problem.

In addition, some of these small-packet services are present on certain network segments where bandwidth may be scarce (residential access, aggregation networks, satellite links), or a pps limit exists. In the context of mobile networks:

- New VoIP services are using data links instead of establishing traditional voice calls (e.g., viber)
- Online games are being played with tablets and smartphones: http://www.juniperresearch.com/viewpressrelease.php?id=534&pr=364
- Internet of Things: many "things" will send small packets with a certain frequency
- New traffic patterns: "Major changes in traffic characteristics are the increases in small packets, short connections, signaling and data traffic, and abnormal traffic. For Universal Mobile Telecommunications System (UTMS) networks in idle status, all these changes lead to sharp increases on signaling and other system resource load. They also bring severe threat on network performance, and affect application data throughput capability and network profitability in the long run." (Huawei Smartphone Solutions White Paper).

The mobility of the users has some other implications: The network may experience a "traffic rush" in certain places or moments (e.g., a sports event, the World release of a new game), so TCM-TF would provide a certain degree of flexibility (a tradeoff): I don't have to over-dimension my network. When a traffic rush is detected, I can get advantage of this tradeoff, compressing traffic up to 50 or 60%, at the cost of a small added latency. The service would work a bit more slowly, but it would at least work.

In addition, if I only "awake" TCM-TF optimization when I have a lot of traffic, then I will add a really tiny latency, since I will have lots of packets to multiplex, and in 5ms I may be able to create an MTU-sized multiplexed packet.

Any other ideas?

Jose

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] Answers to possible questions in the BOF

Thanks!

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 3 Jul 2013 16:29:47 +0200

You are right, Michael.

Sometimes you can prevent the stall. For example, in the release of a new
online game, you can predict that everybody will be waiting in front of the
computer at 0:00 AM in order to be the first ones playing: see what happened
some months ago when “Diablo III” was released (the “launch-day crash”):

<http://www.nbcnews.com/technology/blizzard-apologizes-diablo-disaster-77807
2>
http://www.nbcnews.com/technology/blizzard-apologizes-diablo-disaster-778072

But other times you cannot predict it. For example, think about the amount
of whatsapp messages sent whenever a soccer team scores a goal.

So I think we should definitely think about dynamically using TCM-TF,
integrating different ways for detecting congestion and traffic rushes. In
fact, this is already included in the draft charter, but only as a
possibility for re-chartering, once TCM-TF is well defined (number 9
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00286.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00286.html):

“dynamically applying TCMTF: a higher entity in charge of deciding when and
where, applying or not 

TCMTF, and what kind of TCMTF, and what multiplexing period. Additional
methods for estimating delay 

would also be required.”

Thanks!

Jose

De: Michael Ramalho (mramalho) [mailto:[email-masked]] 
Enviado el: miércoles, 03 de julio de 2013 14:42
Para: [email-masked]; [email-masked]
Asunto: RE: [tcmtf] Answers to possible questions in the BOF

Jose .. you say: 

“I don’t have to over-dimension my network. When a traffic rush is detected,
I can get advantage of this tradeoff, compressing traffic up to 50 or 60%,
at the cost of a small added latency. The service would work a bit more
slowly, but it would at least work.”

You may have actually over-stated the cost. For such a rush, many of the
http sessions during “the rush” would stall (go into slow-start). For that
subset you may have prevented the stall! Thus while most of the sessions may
incur the cost of “small added latency” (of ~40ms or less), some of the
sessions avoided stalling entirely!

I hate it when a web page tries to fetch 100 things … and the http get of
ONE of those things stalls … and prevents me from using site as intended.
Preventing stalls is a good thing.

Also on the “traffic rush” issue … TCMTF can be used dynamically to lessen
bufferbloat (effectively lowering the amount of buffer used on highly
buffered links) on a particular egress link. That is, if you see your egress
buffer growing, you might try to compress traffic toward it when you can.
That could even lessen the delay for all users at such a sports event (lots
of small packets representing updates to game statistics).

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jose Saldana
Sent: Wednesday, July 03, 2013 6:44 AM
To: [email-masked]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

Answer (some ideas):

- Internet of Things: many “things” will send small packets with a certain
frequency

- New traffic patterns: “Major changes in traffic characteristics are the
increases in small packets, short connections, signaling and data traffic,
and abnormal traffic. For Universal Mobile Telecommunications System (UTMS)
networks in idle status, all these changes lead to sharp increases on
signaling and other system resource load. They also bring severe threat on
network performance, and affect application data throughput capability and
network profitability in the long run.” (Huawei Smartphone Solutions White
Paper).

The mobility of the users has some other implications: The network may
experience a “traffic rush” in certain places or moments (e.g., a sports
event, the World release of a new game), so TCM-TF would provide a certain
degree of flexibility (a tradeoff): I don’t have to over-dimension my
network. When a traffic rush is detected, I can get advantage of this
tradeoff, compressing traffic up to 50 or 60%, at the cost of a small added
latency. The service would work a bit more slowly, but it would at least
work.

In addition, if I only “awake” TCM-TF optimization when I have a lot of
traffic, then I will add a really tiny latency, since I will have lots of
packets to multiplex, and in 5ms I may be able to create an MTU-sized
multiplexed packet.

Any other ideas?

Jose

Thanks!

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 3 Jul 2013 17:58:31 +0200

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

> De: [email-masked] [mailto:[email-masked]] En nombre de
> jsalazar
> Enviado el: lunes, 01 de julio de 2013 20:50
> Para: [email-masked]
> 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.
> 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
> 
> 258082.html

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 3 Jul 2013 18:51:00 +0000

|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). Combining it with multiplexing the entire packets could provide significant reduction in the header overhead, especially for IPv6, I think.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing (dwing)
|Sent: Monday, July 01, 2013 10:25 PM
|To: [email-masked]
|Cc: [email-masked]; [email-masked]
|Subject: Re: [tcmtf] Answers to possible questions in the BOF
|
|
|On Jun 28, 2013, at 1:57 AM, [email-masked] 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 <[email-masked]> ha escrito:
|>
|>>
|>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <[email-masked]> 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: [email-masked] [mailto:[email-masked]] En  nombre de Jose Saldana
|>>> Enviado el: lunes, 24 de junio de 2013 13:00
|>>> Para: [email-masked]
|>>> 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
|>>> [email-masked]
|>>> https://www.ietf.org/mailman/listinfo/tcmtf
|>>
|>>
|>
|>
|>
|
|_______________________________________________
|tcmtf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Dan Wing <[email-masked]>
Date: Wed, 3 Jul 2013 11:55:43 -0700

On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]> wrote:

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 4 Jul 2013 13:41:49 +0000

|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: [email-masked]; [email-masked]; [email-masked]
|Subject: Re: [tcmtf] Answers to possible questions in the BOF
|
|
|On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing (dwing)
|> |Sent: Monday, July 01, 2013 10:25 PM
|> |To: [email-masked]
|> |Cc: [email-masked]; [email-masked]
|> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
|> |
|> |
|> |On Jun 28, 2013, at 1:57 AM, [email-masked] 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 <[email-masked]> ha escrito:
|> |>
|> |>>
|> |>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <[email-masked]> 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: [email-masked] [mailto:[email-masked]] En  nombre de Jose Saldana
|> |>>> Enviado el: lunes, 24 de junio de 2013 13:00
|> |>>> Para: [email-masked]
|> |>>> 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
|> |>>> [email-masked]
|> |>>> https://www.ietf.org/mailman/listinfo/tcmtf
|> |>>
|> |>>
|> |>
|> |>
|> |>
|> |
|> |_______________________________________________
|> |tcmtf mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 8 Jul 2013 09:28:44 +0200

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:[email-masked]] 
Enviado el: jueves, 04 de julio de 2013 19:36
Para: [email-masked]
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ó:
> 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:
> 
> Origin 2     <----20 secured flows --------> TCM-IO <------1
> tunnel------> TCM-EO <-------- 20 secured flows----> destination 1, 2,
> 20
> ...
> Origin 20
> 
> 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
> 
> De: [email-masked] [mailto:[email-masked]] En nombre 
> de jsalazar Enviado el: lunes, 01 de julio de 2013 20:50
> Para: [email-masked]
> 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.
> 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.
> 
> > 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.
> >
> > 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?
> >
> > 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
> >
> >
> >
> > gives bandwidth savings on the access link, but consumes  
> > considerable CPU horsepower on the aggregation router (to perform  cRTP), but
> > 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 
> > nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00
> > Para: [email-masked]
> > ask in the BOF. Obviously, we also need answers, so we should  cooperate.
> >

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 08 Jul 2013 09:59:06 +0000

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,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

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

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 8 Jul 2013 16:56:42 +0200

So it seems that the possibility of a document about Security & TCM-TF might
be interesting. What about adding a sentence in the Charter (re-chartering
paragraph), talking about that possibility?

....
9. If other interesting features are identified, the group would re-charter
and include them, e.g., a 
mechanism for a multiplexer to discover a de-multiplexer, and vice versa; a
mechanism to select an 
optimal multiplexer and a de-multiplexer when there are more than one
muxer/de-muxer for a flow; 
dynamically applying TCMTF: a higher entity in charge of deciding when and
where, applying or not 
TCMTF, and what kind of TCMTF, and what multiplexing period. Additional
methods for estimating delay 
would also be required; *security issues related to TCM-TF, and methods for
securing TCM optimized flows.*
....

Jose

> Diego R. Lopez
> Enviado el: lunes, 08 de julio de 2013 11:59
> Para: <[email-masked]>
> CC: <[email-masked]>; Muthu Arul Mozhi Perumal (mperumal); jsalazar; Dan
> Wing
> 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
> 
> > 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,
> 
> > It seems that we have identified some cases in which different security
> options are possible. The question here is:
> >
> > De: jsalazar [mailto:[email-masked]] Enviado el: jueves, 04 de
> > julio de 2013 19:36
> > Para: [email-masked]
> > 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
> >
shattered
> egos"
> >> 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.
> >>
> >>
> >> tunnel------> TCM-EO <-------- 20 secured flows----> destination 1,
> >> tunnel------> 2,
> >> 20
> >> ...
> >> Origin 20
> >>
> >> But I have some additional requirements: I need processing capacity
> >> in the TCM optimizers, and the endpoints should trust them.
> >>
> >>
traffic.
> >>> 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
> >>> tunnel exists, why not optimizing this traffic when possible? We
> cRTP), but
> nombre
> >>> de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00
> >>> Para: [email-masked]
> 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:

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 9 Jul 2013 12:43:11 +0200

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

aspect.
according
they
must
tunnel
three
pre-
included in
one
shattered
traffic.

---

From: [email-masked]
Date: Tue, 9 Jul 2013 11:55:46 +0100

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

>> This

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 10 Jul 2013 09:50:37 +0200

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

> Muthu Arul Mozhi Perumal (mperumal)
> Enviado el: jueves, 04 de julio de 2013 15:42
> Para: Dan Wing (dwing)
> CC: [email-masked]; [email-masked]; [email-masked]
> 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:
> 
> |> |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).
> |>
> |> Combining it with multiplexing the entire packets could provide
> |> significant reduction in the header
> |> |From: [email-masked] [mailto:[email-masked]] On
> |> |Behalf Of Dan Wing (dwing)
> |> |> 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
> |> |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
> |> |>
> |> |>
> |> |>
> |> |>>> 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
> |> |>>> - 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
> |> |>>> - *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?
> |> |>> "Cisco adds IP multiplexing to mobile satellite package", April
> |> |>> 2012,
> |> |http://www.networkworld.com/news/2012/040912-cisco-ip-
> multiplexing-2
> |> |58082.html
> |> |>>
> |> |>>
> |> |>>
> |> |>>>
> |> |>>>
> |> |>> Some networks, today, use cRTP (RFC2508) on their access links.
This
> gives bandwidth savings
> |> |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
> |> |>>> De: [email-masked] [mailto:[email-masked]] En
> |> |>>> nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013
> |> |>>> 13:00
> |> |>>> I would like to start a thread about possible questions people
> |> |>>> may  ask in the BOF. Obviously,
> |we
> |> |>>> This is different from the "questions to ask in the BOF". This
will  be

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 10 Jul 2013 09:50:50 +0200

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

> De: [email-masked] [mailto:[email-masked]]
> Enviado el: martes, 09 de julio de 2013 12:56
> Para: [email-masked]
> CC: 'Diego R. Lopez'; [email-masked]; 'Muthu Arul Mozhi Perumal
> (mperumal)'; 'jsalazar'; 'Dan Wing'
> 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.
> 
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,
> >
> > 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.
> >
> >
> >> de Diego R. Lopez Enviado el: lunes, 08 de julio de 2013 11:59
> >> CC: <[email-masked]>; Muthu Arul Mozhi Perumal (mperumal); jsalazar;
> >> Dan Wing
> >> 1) Applying TCMTF to enhance (or provide a better support to)
> >> security network services, like IPsec or VPNs
> >>
> >> 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
> >>
> >> 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
> >> 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.
> >> >
> >> the "Security Considerations" section of the framework document, and
> >> a further document on this be considered in a further stage.
> >>
> >> Be goode,
> >>
> >> 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
> >> >> 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:
> >> >>
> >> >> tunnel------> TCM-EO <-------- 20 secured flows----> destination
> >> >> tunnel------> 1, 2,
> >> >> 20
> >> >> ...
> >> >> Origin 20
> >> >>
> >> >> But I have some additional requirements: I need processing
> >> >> capacity in the TCM optimizers, and the endpoints should trust them.
> >> >>
> >> >>
> >> >> nombre de jsalazar Enviado el: lunes, 01 de julio de 2013 20:50
> >> >> Para: [email-masked]
> >> >> 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
> >> >> The first possibility is not a great technological sophistication
> >> >> and the second one might consider the first one as a possible
> >> >> additional service.
> >> >> Therefore,
> >> >> employ secure tcm-tf, they must trust the service fully and
> >> >> consider delegating the use of their keys (including private ones)
to
> tcm-tf.
> >> >>> 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.
> >> >>> 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.
> >> >>>
> >> >>> 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
> >> >>> 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.
> >> >>> optimizing specific flows with very tight delay requirements,
> >> >>> - *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.
> >> >>>
> >> >>> the bandwidth could be saved on the access link, across  the
> >> >>> core, and on the far-end access link -- all without the CPU
> >> >>> 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.
> >> >>>
> >> 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:

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 10 Jul 2013 10:00:27 +0000

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:[email-masked]]
|Sent: Wednesday, July 10, 2013 1:21 PM
|To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing)
|Cc: [email-masked]; [email-masked]
|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: [email-masked] [mailto:[email-masked]] En nombre de
|> Muthu Arul Mozhi Perumal (mperumal)
|> Enviado el: jueves, 04 de julio de 2013 15:42
|> Para: Dan Wing (dwing)
|> CC: [email-masked]; [email-masked]; [email-masked]
|> 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: [email-masked]; [email-masked]; [email-masked]
|> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
|> |
|> |
|> |On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal)
|> <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
|> |> |Behalf Of Dan Wing (dwing)
|> |> |Sent: Monday, July 01, 2013 10:25 PM
|> |> |To: [email-masked]
|> |> |Cc: [email-masked]; [email-masked]
|> |> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
|> |> |
|> |> |
|> |> |On Jun 28, 2013, at 1:57 AM, [email-masked] 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 <[email-masked]> ha escrito:
|> |> |>
|> |> |>>
|> |> |>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <[email-masked]>
|> 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: [email-masked] [mailto:[email-masked]] En
|> |> |>>> nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013
|> |> |>>> 13:00
|> |> |>>> Para: [email-masked]
|> |> |>>> 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
|> |> |>>> [email-masked]
|> |> |>>> https://www.ietf.org/mailman/listinfo/tcmtf
|> |> |>>
|> |> |>>
|> |> |>
|> |> |>
|> |> |>
|> |> |
|> |> |_______________________________________________
|> |> |tcmtf mailing list
|> |> [email-masked]
|> |> |https://www.ietf.org/mailman/listinfo/tcmtf
|>
|> _______________________________________________
|> tcmtf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 11 Jul 2013 10:44:04 +0200

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

> De: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
> Enviado el: miércoles, 10 de julio de 2013 12:00
> Para: [email-masked]; Dan Wing (dwing)
> CC: [email-masked]; [email-masked]
> |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
> 
> |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.
> |> De: [email-masked] [mailto:[email-masked]] En nombre
> |> de Muthu Arul Mozhi Perumal (mperumal) Enviado el: jueves, 04 de
> |> julio de 2013 15:42
> |> 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:
> |>
> |> |> |the
> |> |> |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).
> |> |>
> |> |> |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
> |> |> |We would not be able to change IPsec any more than we could
> |> |> |change TCP, so I would not look at how
> |> |to
> |> |> |reduction.  I don't think there are enough bytes in an IPsec
> |> |> |header to bother trying to do IPsec header compression (SPI and
> |> |> |sequence
> |> |> |>>> Question 4: Is TCM-TF interesting for the Industry? Should
> |> |> |>>> the
> |IETF
> |> standardize this?
> |> |> |>>>
> |> |> |>>> Answer:
> |> |> |>>>
> |> |> |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.
> |> |> |delay requirements,  which network operators have to take care of
> |> |> |in a
> |> special way.
> |> |> |>>> - *End to end* optimization: Nowadays, many appliances are
> |> |> |>>> used to  connect remote offices of
> |> |the
> |> |> |>> "Cisco adds IP multiplexing to mobile satellite package",
> |> |> |>> April 2012,
> |> |> |>>> I would like to start a thread about possible questions
> |> |> |>>> people may  ask in the BOF. Obviously,
> |> |we
> |> |> |>>> This is different from the "questions to ask in the BOF".
> |> |> |>>> This
> |will  be
> |> discussed separately.
> |> |> |>>>
> |> |> |>>> Thanks!
> |> |> |>>>
> |> |> |>>> Jose
> |> |> |>>>

---

From: jltornos <[email-masked]>
Date: Thu, 11 Jul 2013 12:41:51 +0200

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ó:
> tunnel------>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 11 Jul 2013 13:06:58 +0000

|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

That's one of the use cases, but looks less interesting to me because of having to perform IPSec twice.

I was thinking of the case where there is an IPSec tunnel between two routers...a typical deployment for securing connection between two branches of an organization over the Internet. Those two routers can perform TCMTF and use the IPSec tunnel for transporting the multiplexed + compressed packets. In effect, we have:

N packets-->[compression]-->N packets with headers compressed--+
                                                               |
1 encrypted packet<--[encryption]<--1 packet--[multiplexing]<--+            
|
+-->[tunneling]--> 1 tunneled encrypted multiplexed compressed packet

This is TCMTFSec (TCMTF + IPSec) -:)

Both TCMFT and IPSec would need some changes..

Muthu

|-----Original Message-----
|From: jltornos [mailto:[email-masked]]
|Sent: Thursday, July 11, 2013 4:12 PM
|To: [email-masked]
|Cc: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
|Subject: Re: [tcmtf] Answers to possible questions in the BOF
|
|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:[email-masked]]
|> Enviado el: miércoles, 10 de julio de 2013 12:00
|> Para: [email-masked]; Dan Wing (dwing)
|> CC: [email-masked]; [email-masked]
|> 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:[email-masked]]
|> |Sent: Wednesday, July 10, 2013 1:21 PM
|> |To: Muthu Arul Mozhi Perumal (mperumal); Dan Wing (dwing)
|> |Cc: [email-masked]; [email-masked]
|> |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: [email-masked] [mailto:[email-masked]] En nombre
|> |> de Muthu Arul Mozhi Perumal (mperumal) Enviado el: jueves, 04 de
|> |> julio de 2013 15:42
|> |> Para: Dan Wing (dwing)
|> |> CC: [email-masked]; [email-masked]; [email-masked]
|> |> 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: [email-masked]; [email-masked]; [email-masked]
|> |> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
|> |> |
|> |> |
|> |> |On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal)
|> |> <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
|> |> |> |Behalf Of Dan Wing (dwing)
|> |> |> |Sent: Monday, July 01, 2013 10:25 PM
|> |> |> |To: [email-masked]
|> |> |> |Cc: [email-masked]; [email-masked]
|> |> |> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
|> |> |> |
|> |> |> |
|> |> |> |On Jun 28, 2013, at 1:57 AM, [email-masked] 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 <[email-masked]> ha escrito:
|> |> |> |>
|> |> |> |>>
|> |> |> |>> On Jun 26, 2013, at 3:49 AM, Jose Saldana
|> <[email-masked]>
|> |> 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: [email-masked] [mailto:[email-masked]]
|> En
|> |> |> |>>> nombre de Jose Saldana Enviado el: lunes, 24 de junio de
|> 2013
|> |> |> |>>> 13:00
|> |> |> |>>> Para: [email-masked]
|> |> |> |>>> 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
|> |> |> |>>> [email-masked]
|> |> |> |>>> https://www.ietf.org/mailman/listinfo/tcmtf
|> |> |> |>>
|> |> |> |>>
|> |> |> |>
|> |> |> |>
|> |> |> |>
|> |> |> |
|> |> |> |_______________________________________________
|> |> |> |tcmtf mailing list
|> |> |> [email-masked]
|> |> |> |https://www.ietf.org/mailman/listinfo/tcmtf
|> |>
|> |> _______________________________________________
|> |> tcmtf mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/tcmtf
|>
|>
|> _______________________________________________
|> tcmtf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Dan Wing <[email-masked]>
Date: Fri, 12 Jul 2013 08:42:03 -0700

> securing TCM optimized flows.*

This text detracts from the charter, because it lists only one reason we might re-charter to broaden the WG's scope.  There are lots of reasons we might re-charter to broaden the WG's scope, of course.  So I don't think this text is really saying anything that needs to be said.

-d

>>>> traveling through a "dangerous" network segment (perhaps a tunnel

---

From: Dan Wing <[email-masked]>
Date: Fri, 12 Jul 2013 08:53:11 -0700

> 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, ...").

> 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

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Jul 2013 10:52:53 -0500

> This text detracts from the charter, because it lists only one reason we might re-charter to broaden the WG's scope.  There are lots of reasons we might re-charter to broaden the WG's scope, of cou…

Dan, I broadly agree that you don't want a list of reasons to re-charter 
before you can do work in the charter. I suggested shorter text to Jose 
privately, seconds ago :-)

Spencer

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 15 Jul 2013 11:30:37 +0200

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

> Enviado el: viernes, 12 de julio de 2013 17:53
> Para: [email-masked]
> CC: [email-masked]; 'Diego R. Lopez'; [email-masked]; 'Muthu Arul
> Mozhi Perumal (mperumal)'; 'jsalazar'
> > 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]).
> > 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.
> >
> > 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
> >
> >> De: [email-masked] [mailto:[email-masked]] Enviado el:
> >> martes, 09 de julio de 2013 12:56
> >> Para: [email-masked]
> >> - 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 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,
> >>>
> >>> considerations" section in the end. The idea is talking about the
> >>> two options (as summarized by Diego):
> >>>
> >>> - Applying TCMTF to enhance (or provide a better support to)
> >>> 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
> >>> 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.
> >>>
> >>>
> >>>> nombre de Diego R. Lopez Enviado el: lunes, 08 de julio de 2013
> >>>> 11:59
> >>>> CC: <[email-masked]>; Muthu Arul Mozhi Perumal (mperumal);
> >>>> jsalazar; Dan Wing
> >>>> We'd have to go into more detail to evaluate potential savings, but
> >>>> I have the feeling
> >>> they
> >>>> 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
> >>>> the "Security Considerations" section of the framework document,
> >>>> and a further document on this be considered in a further stage.
> >>>>
> >>>> Be goode,
> >>>>
> >>>> 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.
> >>>>>> 2- Using TCM for optimizing already secured communications: I
> >>>>>> have a bunch of already secured flows. Which is the best way for
> >>>>>> 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.
> >>>>>> every time we use the term "secure tcm-tf" should think the
> >>>>>> second option, for generality.
> >>>> 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:

---

From: Dan Wing <[email-masked]>
Date: Mon, 15 Jul 2013 09:30:36 -0700

>    	authentication or encryption.

Splendid.

>    	are optimized by means of TCM, and the addition of further security

I would remove "and the addition of further security is not necessary" phrase, because that phrase implies we are going to detect IPsec ESP packets and then not put them into an IPsec-protected tunnel.  Said another way, the phrase implies the already-encrypted packets are "routed around" (outside) of the IPsec tunnel.  This is risky, and deserves its own security analysis and discussion; let's not go there.

> 	of the network infrastructure, is for future study.

That text reads nicely.

-d

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 23 Jul 2013 17:27:54 +0200

Today I have been talking with Bob Briscoe (in cc) and he has asked me this
question (more or less). Since it is interesting, I would like to hear the
opinion of the list.

Question 7: There exist proprietary products (WAN accelerators and
Performance Enhancing Proxies (PEPs) which are able to optimize traffic.

How will those companies respond to attempts to standardize these protocols?
Will it be a problem for them? Will it be interesting?

My answer (more ideas required):

WAN accelerators and PEPs are only part of the involved actors. That is the
end-to-end case, in which the end user performs the optimization, and the
network does not intervene. I think a standard would be interesting, in
order to permit devices from different companies to interact and optimize
traffic.

But there is still another case: optimization within the network. Network
operators may be interested because they can find paths in the network
shared by a lot of small-packet flows, so optimization can also be
interesting there. Perhaps the optimizers can be dormant, and be activated
only when required (a traffic rush at certain places or moments).

And sometimes the optimization can take place between an end-user device and
an operator device. For example, an internet café or a rural village in a
developing country, with a single connection shared by a number of people.
So a standard protocol for doing that can also be interesting.

Or e.g. two network operators may sign an agreement in order to optimize
traffic flows between their aggregation networks. A standard is then
necessary.

Any other ideas? Any other reasons for standardization?

Thanks, Bob and everybody.

Jose

Thanks!

Jose

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 23 Jul 2013 16:18:36 +0000

Hi,

I think that we could add the possibility of leveraging TCM in the case encapsulation approaches are in use, like mobility (LISP) or security (IPsec)

Be goode,

On 23 Jul 2013, at 17:27 , Jose Saldana wrote:

Today I have been talking with Bob Briscoe (in cc) and he has asked me this question (more or less). Since it is interesting, I would like to hear the opinion of the list.

Question 7: There exist proprietary products (WAN accelerators and Performance Enhancing Proxies (PEPs) which are able to optimize traffic.

How will those companies respond to attempts to standardize these protocols? Will it be a problem for them? Will it be interesting?

WAN accelerators and PEPs are only part of the involved actors. That is the end-to-end case, in which the end user performs the optimization, and the network does not intervene. I think a standard would be interesting, in order to permit devices from different companies to interact and optimize traffic.

But there is still another case: optimization within the network. Network operators may be interested because they can find paths in the network shared by a lot of small-packet flows, so optimization can also be interesting there. Perhaps the optimizers can be dormant, and be activated only when required (a traffic rush at certain places or moments).

And sometimes the optimization can take place between an end-user device and an operator device. For example, an internet café or a rural village in a developing country, with a single connection shared by a number of people. So a standard protocol for doing that can also be interesting.

Or e.g. two network operators may sign an agreement in order to optimize traffic flows between their aggregation networks. A standard is then necessary.

Jose

Thanks!

Jose

_______________________________________________
tcmtf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcmtf

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091