Subject: [Megaco] Fw: Question on H.248.37 Amendment 1

From: [email-masked]
Date: Sat, 14 Oct 2006 07:51:19 +0200

... forward Reinaldo's question first to MEGACO list ...

----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 14.10.2006 07:50 -----
                                                                                                                                        
                      "Reinaldo Penno"                                                                                                  
                      <rpenno@juniper.         To:      <[email-masked]>                                                               
                      net>                     cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL                                             
                                               Subject: Question on H.248.37 Amendment 1                                                
                      14.10.2006 01:06                                                                                                  

Hello SG16/Albrecht,

I have some question from a media Gateway perspective related to this
document.

In section:

"5.6.3             NAPT traversal processing: 'RELATCH' mode
When the NAT traversal processing signal with parameter NAPT on a
termination/stream is set to RELATCH, then the MG will perform a similar
process to the latching process described above. The difference is that
the MG will check for a change of source IP address/port on the incoming
media stream. If/when a new source IP address and/or port are detected,
then they will be used as the destination address and port for future
outgoing packets. After re-latching, any packets received on the old
source address and port combination will be considered as malicious and
will be treated accordingly (discarded and counted; see sub-clause
5.6.x)."

Security Questions:
===================

b) Many VoIP phones change the source port (but not source IP address)
of the same media stream constantly (as expected for UDP socket
implementation). Is the Termination on the Media Gateway supposed to
change the destination port of the outgoing stream to match that of a
received packet? The endpoint might not accept media on a different port
than the one present in the SDP.

C) In order to perform RE-LATCH we need to potentially match/operate on
packets with specified destination IP address/port but unknown source IP
address/port.

It seems to me this is a security problem, since an attacker can inject
a single RTP packet with "his" source IP address/port and easily hijack
VoIP media to his endpoint since in LATCH/RE-LATCH mode would send
packets automatically to this new IP address/port.

d) Or an attacker can keep sending media packets with random source IP
addresses/ports to many terminations (with RE-LATCH present) and
completely bring many calls down since media would be sent everywhere
but the intended locations.

Architecture questions:
=======================

E) How this plays with SDP filtering
(http://www.ietf.org/rfc/rfc4570.txt) ? If a endpoint provides filtering
in its SDP information (which is only known to the other endpoint and
possibly Media controller) and the Media Gateway receives an packet with
an IP address/port that would match the filter how this could be
enforced? Specially in the light of LATCH/RE-LATCH

F) The document does not describe how LATCH/RE-LATCH could be used with
connection oriented media streams (e.g. TCP). Accepting a TCP packet
from a different source IP address/port would mean overriding any NAT
proper behavior since the sequence numbers would surely differ and
cannot be kept in sycn.

I would appreciate your comments regarding these questions.

Thanks,

-Reinaldo

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 14 Oct 2006 02:24:40 -0400

Thanks Albrecht, I did not know this list was still active. That's good,
since I felt there was no proper place to discuss H.248 extension
packages.

I will be sending my other questions to the megaco list as well.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 10:51 PM
> To: [email-masked]
> Cc: Reinaldo Penno
> Subject: Fw: Question on H.248.37 Amendment 1
> 
> I have some question from a media Gateway perspective related 
> to this document.
> 
> In section:
> 
> When the NAT traversal processing signal with parameter NAPT 
> on a termination/stream is set to RELATCH, then the MG will 
> perform a similar process to the latching process described 
> above. The difference is that the MG will check for a change 
> of source IP address/port on the incoming media stream. 
> If/when a new source IP address and/or port are detected, 
> then they will be used as the destination address and port 
> for future outgoing packets. After re-latching, any packets 
> received on the old source address and port combination will 
> be considered as malicious and will be treated accordingly 
> (discarded and counted; see sub-clause 5.6.x)."
> 
> Security Questions:
> ===================
> 
> b) Many VoIP phones change the source port (but not source IP 
> address) of the same media stream constantly (as expected for 
> UDP socket implementation). Is the Termination on the Media 
> Gateway supposed to change the destination port of the 
> outgoing stream to match that of a received packet? The 
> endpoint might not accept media on a different port than the 
> one present in the SDP.
> 
> C) In order to perform RE-LATCH we need to potentially 
> match/operate on packets with specified destination IP 
> address/port but unknown source IP address/port.
> 
> It seems to me this is a security problem, since an attacker 
> can inject a single RTP packet with "his" source IP 
> address/port and easily hijack VoIP media to his endpoint 
> since in LATCH/RE-LATCH mode would send packets automatically 
> to this new IP address/port.
> 
> d) Or an attacker can keep sending media packets with random 
> source IP addresses/ports to many terminations (with RE-LATCH 
> present) and completely bring many calls down since media 
> would be sent everywhere but the intended locations.
> 
> Architecture questions:
> =======================
> 
> (http://www.ietf.org/rfc/rfc4570.txt) ? If a endpoint 
> provides filtering in its SDP information (which is only 
> known to the other endpoint and possibly Media controller) 
> and the Media Gateway receives an packet with an IP 
> address/port that would match the filter how this could be 
> F) The document does not describe how LATCH/RE-LATCH could be 
> used with connection oriented media streams (e.g. TCP). 
> Accepting a TCP packet from a different source IP 
> address/port would mean overriding any NAT proper behavior 
> since the sequence numbers would surely differ and cannot be 
> kept in sycn.
>