Subject: [ippm] Comments on draft-mirsky-ippm-twamp-refl-registered-port

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 28 Jul 2016 20:58:46 +0000

Hi,

I've gone through the draft, which presents an interesting idea from an operator perspective. However there are some points not yet clear for me, that maybe need to be clarified in the draft. Please, find here below a number of comments:

·         What about scenarios where one endpoint is simultaneously tested from several other flow generators? I'm referring for instance to cases like the testing of X2 interfaces in LTE scenarios. For example, and eNB could receive a number of testing flows from other neighboring eNBs. Just using (or having) one well-known port could not be sufficient for cases like this.

·         The objective of using this well-known port approach seems to be justified as a way of simplifying the logic of the reflector. However section 3, last paragraph, seems to state (in my understanding) that in case of any issue it will be possible to rely on the conventional TWAMP signaling. Then it seems that the support of the signaling is yet required because of the backward compatibility. Then, what is the real advantage for the end device, if finally we need the signaling suite for backward compatibility anyway?

·         I'm not so sure that further security considerations could not be needed in this case. As far as the port is defined, DoS attacks and other malicious behaviors could be focus on it. Also it is required to understand what could be the port to be used when the reflector is also sender, in order to avoid fraudulent use as well by third parties or man-in-the-middle attacks

Thanks in advance for any further clarification. As mentioned, I see potential advantages by using this approach, but probably some refinements are yet needed (or even recommendations of usage) in order to have a real operational case.

Thanks

Best regards

Luis

__________________________________
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
[email-masked]<mailto:[email-masked]>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Foote, Footer (Nokia - CA)" <[email-masked]>
Date: Fri, 29 Jul 2016 13:39:39 +0000

Hi Luis,

Thank you for your comments.

I have included some notes below.

Footer
Nokia

From: ippm [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, July 28, 2016 4:59 PM
To: [email-masked]
Subject: [ippm] Comments on draft-mirsky-ippm-twamp-refl-registered-port

Hi,

.         What about scenarios where one endpoint is simultaneously tested from several other flow generators? I'm referring for instance to cases like the testing of X2 interfaces in LTE scenarios. For example, and eNB could receive a number of testing flows from other neighboring eNBs. Just using (or having) one well-known port could not be sufficient for cases like this.

[Footer - If I understand correctly, the X2 reference point is a logical IP connection between neighboring EnodeBs. The IP flows (sessions) can be distinguished by the tuple of SIP, DIP, SP, DP.  If multiple IP flows (sessions) are coming from the same SourceIP (e.g. multiple test sessions say with different QoS marking) the Source UPD Port will be different.  If multiple IP flows (sessions) are coming from different sources (e.g. testing an X2 mesh), then the SourceIP will be different.  All that is required to distinguish the IP flow (session) is one different variable.]

.         The objective of using this well-known port approach seems to be justified as a way of simplifying the logic of the reflector. However section 3, last paragraph, seems to state (in my understanding) that in case of any issue it will be possible to rely on the conventional TWAMP signaling. Then it seems that the support of the signaling is yet required because of the backward compatibility. Then, what is the real advantage for the end device, if finally we need the signaling suite for backward compatibility anyway?

[Footer - The paragraph may need some rewording.  It is meant to say that the TWAMP Receiver UDP Port number (tbd) can also be used in the client/server negotiation when TWAMP Client/Server model is deployed.  It does not cause any backward compatibility for operators that have already deployed TWAMP or wish to deploy TWAMP using the Client/Server model. The client should accept the UDP port the Server responds with, in this case that port could be the well-known UDP port.]

.         I'm not so sure that further security considerations could not be needed in this case. As far as the port is defined, DoS attacks and other malicious behaviors could be focus on it. Also it is required to understand what could be the port to be used when the reflector is also sender, in order to avoid fraudulent use as well by third parties or man-in-the-middle attacks

[Footer - Some examples to enhance security could be: filtering access to the UDP port by access lists, using non-routable IPs outside of the domain for the TWAMP loopback, etc.  I think you are correct.  This section may need to be expanded.  On the second point, I would also agree that the well-known UDP port not be used as a source port.]

Thanks

Best regards

Luis

Technology and Planning

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
[email-masked]

________________________________________

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 29 Jul 2016 16:24:08 +0000

Hi Footer

Thanks so much for the clarifications.

One further comment about the first topic.

I think it has also to be taken into consideration the concurrency in the number of the sessions against the same well know port on a given device, I mean, the potential impact of multiple sessions being active at the same time on the same device. Maybe some recommendation or some guidance should be included in the document about that. It could be the case that so many simultaneous sessions could impact to some extent the reported TWAMP result (because of number of sessions, device architecture, etc) depending on variables like the frequency of the (simultaneous) tests. So some words about that would be needed, in my opinion.

As mentioned before I think this is a quite valuable idea. I'm open to help on this in the way you consider more appropriate.

Best regards

Luis

-----Mensaje original-----
De: Foote, Footer (Nokia - CA) [mailto:[email-masked]]
Enviado el: viernes, 29 de julio de 2016 15:40
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Asunto: RE: Comments on draft-mirsky-ippm-twamp-refl-registered-port

Hi Luis,

Footer
Nokia

Hi,

Thanks

Best regards

Luis

Technology and Planning
Transport, IP and Interconnection Networks Telefónica I+D / Global CTO unit / Telefónica