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

[Dan Wing <[e-mail]>]

On Jul 15, 2013, at 2:30 AM, Jose Saldana <[e-mail]> wrote:

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

Splendid.

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

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.


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

That text reads nicely.

-d


> Thanks,
> 
> Jose
> 
>> -----Mensaje original-----
>> De: Dan Wing [mailto:[e-mail]]
>> Enviado el: viernes, 12 de julio de 2013 17:53
>> Para: [e-mail]
>> CC: [e-mail]; 'Diego R. Lopez'; [e-mail]; 'Muthu Arul
>> Mozhi Perumal (mperumal)'; 'jsalazar'
>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>> 
>> 
>> On Jul 10, 2013, at 12:50 AM, Jose Saldana <[e-mail]> wrote:
>> 
>>> 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.
>> 
>> 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, ...").
>> 
>>> 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.
>>> -----
>> 
>> 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
>>> 
>>>> -----Mensaje original-----
>>>> De: [e-mail] [mailto:[e-mail]] Enviado el:
>>>> martes, 09 de julio de 2013 12:56
>>>> Para: [e-mail]
>>>> CC: 'Diego R. Lopez'; [e-mail]; 'Muthu Arul Mozhi Perumal
>>>> (mperumal)'; 'jsalazar'; 'Dan Wing'
>>>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>>>> 
>>>> 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
>>>> 
>>>> 
>>>>> 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
>>>>> 
>>>>>> -----Mensaje original-----
>>>>>> De: [e-mail] [mailto:[e-mail]] En
>>>>>> nombre de Diego R. Lopez Enviado el: lunes, 08 de julio de 2013
>>>>>> 11:59
>>>>>> Para: <[e-mail]>
>>>>>> CC: <[e-mail]>; Muthu Arul Mozhi Perumal (mperumal);
>>>>>> jsalazar; Dan Wing
>>>>>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>>>>>> 
>>>>>> 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,
>>>>>> 
>>>>>> On 8 Jul 2013, at 09:28 , Jose Saldana wrote:
>>>>>> 
>>>>>>> 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:[e-mail]] Enviado el: jueves, 04 de
>>>>>>> julio de 2013 19:36
>>>>>>> Para: [e-mail]
>>>>>>> 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ó:
>>>>>>>> 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
>>>>>>>> tunnel------> 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
>>>>>>>> 
>>>>>>>> -----Mensaje original-----
>>>>>>>> De: [e-mail] [mailto:[e-mail]] En
>>>>>>>> nombre de jsalazar Enviado el: lunes, 01 de julio de 2013 20:50
>>>>>>>> Para: [e-mail]
>>>>>>>> Asunto: Re: [tcmtf] Answers to possible questions in the BOF
>>>>>>>> 
>>>>>>>> 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ó:
>>>>>>>>> On Jun 28, 2013, at 1:57 AM, [e-mail] wrote:
>>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> Few days ago Julian talked about TCM-TF's security and now I've
>>>>>>>>> read in the link included by Dan, saying that the gain obtained
>>>>>>>>> when multiplexing Ipsec-encrypted packets is 20-to-1. We have
>>>>>>>>> been looking for more information about this issue and thinking
>>>>>>>>> about a way to reduce the needed  bandwidth in IPsec flows.
>>>>>>>>> 
>>>>>>>>> The main idea is to find a way to change the authentication of
>>>>>>>>> the individual packets and merge all of them in a unique
>>>> authentication.
>>>>>>>>> Thus, instead of using 20 IPsec tunnels, we would have a single
>>>>>>>>> tunnel including 20 flows. Is this something similar than how
>>>>>>>>> Cisco gets the improvement?
>>>>>>>>> 
>>>>>>>>> We would not be able to change IPsec any more than we could
>>>>>>>>> change TCP, so I would not look at how to change IPsec
>>>> authentication.
>>>>>>>>> 
>>>>>>>>> However, if there are a bunch of IPsec packets sharing a common
>>>>>>>>> path, I could see them being successfully multiplexed into one
>>>>>>>>> larger packet at one tunnel endpoint and then de-multiplexed at
>>>>>>>>> the other tunnel endpoint.  This can provide a packet per second
>>>>>>>>> reduction.  I don't think there are enough bytes in an IPsec
>>>>>>>>> header to bother trying to do IPsec header compression (SPI and
>>>>>>>>> sequence
>>>>>> number are only 64 bits).
>>>>>>>>> 
>>>>>>>>> -d
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> José Luis
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Dan Wing <[e-mail]> ha escrito:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <[e-mail]>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Question 4: Is TCM-TF interesting for the Industry? Should the
>>>>>>>>> IETF standardize this?
>>>>>>>>> 
>>>>>>>>> Answer:
>>>>>>>>> 
>>>>>>>>> 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP
>>>>> traffic.
>>>>>>>>> So if RFC4170 was interesting, why not updating it?
>>>>>>>>> 
>>>>>>>>> 2) TCM-TF can be useful in order to save bandwidth in many cases:
>>>>>>>>> 
>>>>>>>>> - Aggregation network of *network operators*: We are saving
>>>>>>>>> bandwidth by optimizing and putting together traffic flows. Is
>>>>>>>>> this interesting for a network operator? What about
>>>> overprovisioning?
>>>>>>>>> The idea is that there are places and moments in which a number
>>>>>>>>> of flows based on small packets are in the same place and at the
>>>>>>>>> same moment. Then, TCM-TF can be applied in order to provide
>>>> flexibility.
>>>>>>>>> We are not optimizing the overall Internet traffic, we are
>>>>>>>>> optimizing specific flows with very tight delay requirements,
>>>>>>>>> which network operators have to take care of in a special way.
>>>>>>>>> www.huawei.com/ilink/en/download/HW_193034
>>>>>>>>> 
>>>>>>>>> - *End to end* optimization: Nowadays, many appliances are used
>>>>>>>>> to connect remote offices of the same company (creating a VPN).
>>>>>>>>> So if a tunnel exists, why not optimizing this traffic when
>>>>>>>>> possible? We would save bandwidth in the access network, where
>>>>>>>>> it
>>>> can be scarce.
>>>>>>>>> 
>>>>>>>>> - Wireless and satellite scenarios.
>>>>>>>>> 
>>>>>>>>> "Cisco adds IP multiplexing to mobile satellite package", April
>>>>>>>>> 2012,
>>>>>>>>> http://www.networkworld.com/news/2012/040912-cisco-ip-
>>>>>> multiplexing-
>>>>>>>> 258082.html
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Any other thoughts? Any other scenarios in mind? Potential
>>>>>>>>> beneficiaries?
>>>>>>>>> 
>>>>>>>>> Some networks, today, use cRTP (RFC2508) on their access links.
>>>>>> This
>>>>>>>>> gives bandwidth savings on the access link, but consumes
>>>>>>>>> considerable CPU horsepower on the aggregation router (to
>>>>>>>>> perform
>>>>>> cRTP), but
>>>>>>>>> provides no bandwidth savings across the network core.   If,
>>>>>> instead,
>>>>>>>>> the bandwidth could be saved on the access link, across  the
>>>>>>>>> core, and on the far-end access link -- all without the CPU
>>>>>>>>> impact on the aggregation router -- it is a considerable win.
>>>>>>>>> 
>>>>>>>>> -d
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Jose
>>>>>>>>> 
>>>>>>>>> De: [e-mail] [mailto:[e-mail]] En
>>>>>> nombre
>>>>>>>>> de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00
>>>>>>>>> Para: [e-mail]
>>>>>>>>> Asunto: [tcmtf] Answers to possible questions in the BOF
>>>>>>>>> 
>>>>>>>>> I would like to start a thread about possible questions people
>>>>>>>>> may ask in the BOF. Obviously, we also need answers, so we
>>>>>>>>> should
>>>>>> cooperate.
>>>>>>>>> 
>>>>>>>>> This is different from the "questions to ask in the BOF". This
>>>>>>>>> will be discussed separately.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> Jose
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> tcmtf mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> tcmtf mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> tcmtf mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> tcmtf mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>> 
>>>>> _______________________________________________
>>>>> tcmtf mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>> 
>>> 
>>> 
> 
>