Subject: [tcmtf] Other potential specific uses of TCM-TF

From: "Jose Saldana" <[email-masked]>
Date: Wed, 19 Jun 2013 16:28:48 +0200

Hi all,

As you may know, if we get the BOF approved, we will have to discuss the WG
charter there. Currently these drafts are included in the WG charter (
<http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf>
http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf):

1- Draft "TCM-TF reference model": the different options which can be used
at each layer. 

2- Draft "TCM-TF negotiation protocol": setup/release a TCMTF session
including a negotiation mechanism to decide the options to use at each
layer.

3- Draft "TCM-TF recommendations": recommendations in order to decide which
packet flows can or can not be multiplexed and how.

For the charter discussion, it would be useful to have in mind (and perhaps
to mention) other potential specific uses of TCM-TF *that might contribute
unique requirements*.

- First of all, I think on the idea proposed by Tomaso and Matteo (DLR), as
said in n.10 of the current draft charter: "specific uses of TCMTF, such as
in wireless and satellite scenarios, could be considered, and it will be
studied whether modifications or extensions are required on the protocol".
It presents different and specific requirements.

- Do you think that instant messaging presents unique requirements with
respect to the normal use of TCM-TF? I don't think so, but perhaps someone
won't agree on this. In fact, instant messaging is already included in the
"TCM-TF recommendations" draft.

Any other ideas?

Jose

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 19 Jun 2013 14:40:31 +0000

Hi,

I think it could be better to mention the study of specific requirements on TCMTF by particular use cases, and consider the inclusion of such documents in a future rechartering, rather than committing to have one document (or even several of them) in an issue that we'll have to clarify once the basic framework is in place.

Be goode,

On 19 Jun 2013, at 16:28 , Jose Saldana wrote:

Hi all,

As you may know, if we get the BOF approved, we will have to discuss the WG charter there. Currently these drafts are included in the WG charter (http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf):

1- Draft “TCM-TF reference model”: the different options which can be used at each layer.
2- Draft “TCM-TF negotiation protocol”: setup/release a TCMTF session including a negotiation mechanism to decide the options to use at each layer.
3- Draft “TCM-TF recommendations”: recommendations in order to decide which packet flows can or can not be multiplexed and how.

For the charter discussion, it would be useful to have in mind (and perhaps to mention) other potential specific uses of TCM-TF *that might contribute unique requirements*.

- First of all, I think on the idea proposed by Tomaso and Matteo (DLR), as said in n.10 of the current draft charter: “specific uses of TCMTF, such as in wireless and satellite scenarios, could be considered, and it will be studied whether modifications or extensions are required on the protocol”. It presents different and specific requirements.

- Do you think that instant messaging presents unique requirements with respect to the normal use of TCM-TF? I don’t think so, but perhaps someone won’t agree on this. In fact, instant messaging is already included in the “TCM-TF recommendations” draft.

Any other ideas?

Jose

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

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: [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: Wed, 19 Jun 2013 16:54:37 +0200

Yes, Diego. I think the idea is having these three “basic” drafts, and also
to have in mind some potential ones which could be addressed by
re-chartering. We have to first build the basic things, and then go to
specific uses. In fact, the current draft charter (n.9) already includes
some of that additional ideas:

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.

I think that in the BOF we should also mention (only mention) the potential
work to be addressed if the WG is created, and the interest on it.

However, there is something dangerous: if we “open” too many things, we may
widen the discussion too much, and the BOF may become unfocused.

What do you think?

Jose

De: Diego R. Lopez [mailto:[email-masked]] 
Enviado el: miércoles, 19 de junio de 2013 16:41
Para: <[email-masked]>
CC: <[email-masked]>; <[email-masked]>; Spencer Dawkins;
<[email-masked]>; Martin Stiemerling
Asunto: Re: [tcmtf] Other potential specific uses of TCM-TF

Hi, 

I think it could be better to mention the study of specific requirements on
TCMTF by particular use cases, and consider the inclusion of such documents
in a future rechartering, rather than committing to have one document (or
even several of them) in an issue that we'll have to clarify once the basic
framework is in place.

Be goode,

Hi all,

1- Draft “TCM-TF reference model”: the different options which can be used
at each layer.

2- Draft “TCM-TF negotiation protocol”: setup/release a TCMTF session
including a negotiation mechanism to decide the options to use at each
layer.

3- Draft “TCM-TF recommendations”: recommendations in order to decide which
packet flows can or can not be multiplexed and how.

- First of all, I think on the idea proposed by Tomaso and Matteo (DLR), as
said in n.10 of the current draft charter: “specific uses of TCMTF, such as
in wireless and satellite scenarios, could be considered, and it will be
studied whether modifications or extensions are required on the protocol”.
It presents different and specific requirements.

- Do you think that instant messaging presents unique requirements with
respect to the normal use of TCM-TF? I don’t think so, but perhaps someone
won’t agree on this. In fact, instant messaging is already included in the
“TCM-TF recommendations” draft.

Any other ideas?

Jose

[email-masked]

Dr Diego R. Lopez
Telefonica I+D

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: Julián Fernández-Navajas <[email-masked]>
Date: Thu, 20 Jun 2013 10:04:16 +0200

Hi all,
I like to add a potencial new idea which could be addressed by 
re-chartering. What about the security on the tunnel?. It is possible to 
add security to TCMTF because it is inherent in the tunnels. And not 
only consider encryption, but also the digital signature which 
represents much loss of efficiency in the case of small packages.
Someone have more knowledge about this issue?
Julián

El 19/06/2013 16:54, Jose Saldana escribió:
> which could be addressed by re-chartering

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 20 Jun 2013 22:13:11 +0200

Dear all,

The TCMTF BOF has been approved for the IETF-87 meeting in Berlin.

The chairs for the BOF will be announced shortly.

   Martin

-- 
IETF Transport Area Director

[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 21 Jun 2013 09:08:46 +0200

Thanks a lot, Martin! This is really good news indeed.

Now, we have to work hard for preparing it.

Thanks to you and to everybody,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> Martin Stiemerling
> Enviado el: jueves, 20 de junio de 2013 22:13
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Asunto: [tcmtf] TCMTF BOF approved for IETF-87 in Berlon
> 
> Dear all,
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 23 Jun 2013 15:38:51 +0000

Hi Julian,

I definitely think you have a point here. 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.

Be goode,

On 20 Jun 2013, at 10:04 , Julián Fernández-Navajas wrote:

Hi all,
I like to add a potencial new idea which could be addressed by re-chartering. What about the security on the tunnel?. It is possible to add security to TCMTF because it is inherent in the tunnels. And not only consider encryption, but also the digital signature which represents much loss of efficiency in the case of small packages.
Someone have more knowledge about this issue?
Julián

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 24 Jun 2013 09:44:17 +0200

Regarding security, we have identified at least one scenario with security
issues:

- We have N flows which are traveling through a “dangerous” network segment
(e.g. the “public” Internet).

- Instead of adding security to each flow (e.g. using IPSec for each flow),
can we multiplex them and use a single security tunnel instead of N security
tunnels.

- It would save bandwidth, since it would avoid N-1 additional security
headers.

1

2

…   ---->TCM-ingress ------> non secure network segment ---------->
TCM-egress ----> flows rebuilt to their native forms

N

The questions are:

Does this scenario exist? i.e. a number of flows traveling through a
“dangerous” network segment. (perhaps a tunnel between appliances connecting
remote offices of a company)

Would this be valid for IPSec in tunnel mode? I would avoid N-1 tunnel
headers.

Would this be valid for IPSec in transport mode? I would avoid N-1 times the
“Authentication header” or the “Encapsulation Security Header”.

Which would be the best way for adding security to TCM?. Perhaps IPSec added
to the tunneling header would be the most straightforward solution.

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de
Diego R. Lopez
Enviado el: domingo, 23 de junio de 2013 17:39
Para: Julián Fernández-Navajas
CC: <[email-masked]>
Asunto: Re: [tcmtf] Other potential specific uses of TCM-TF

Hi Julian, 

I definitely think you have a point here. 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.

Be goode,

Hi all,
I like to add a potencial new idea which could be addressed by
re-chartering. What about the security on the tunnel?. It is possible to add
security to TCMTF because it is inherent in the tunnels. And not only
consider encryption, but also the digital signature which represents much
loss of efficiency in the case of small packages.
Someone have more knowledge about this issue?
Julián

Dr Diego R. Lopez
Telefonica I+D

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

  _____