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

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

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: [e-mail] [mailto:[e-mail]] En nombre de
Diego R. Lopez
Enviado el: domingo, 23 de junio de 2013 17:39
Para: Julián Fernández-Navajas
CC: <[e-mail]>
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,

 

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

El 19/06/2013 16:54, Jose Saldana escribió:

which could be addressed by re-chartering

 

_______________________________________________
tcmtf mailing list
[e-mail]
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: [e-mail]
Tel:    [phone]
Mobile: [phone]
-----------------------------------------

 

 

  _____  


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