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

From: [email-masked]
Date: Wed, 28 Feb 2007 14:52:38 +0100

Reinaldo,
like to resume the discussion concerning your questions against H.248.37.

We've submitted five contributions on Draft H.248.37 Amendment 1:

see AVD-2974 to 2978
on
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/0703_She.html

-Albrecht

                      "Reinaldo Penno"                                                                                               
                      <rpenno@juniper.         To:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <[email-masked]>                       
                      net>                     cc:                                                                                   
                                               Subject: [Megaco] RE: Question on H.248.37 Amendment 1                                
                      14.10.2006 08:24                                                                                               

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

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 28 Feb 2007 11:55:41 -0500

Again, thanks for following up on my questions. Latching and security is
something I'm dealing on a daily basis nowadays.

I'll read the amendements and provide comments.

Thanks,

Reinaldo
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 5:53 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: Re: [Megaco] RE: Question on H.248.37 Amendment 1
> 
> Reinaldo,
> Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <[email-masked]>        
>                
>                       net>                     cc:            
>                                                               
>          
>                                                Subject: 
> [Megaco] RE: Question on H.248.37 Amendment 1                 
>                
>                       14.10.2006 08:24                        
>                                                               
>          
>                                                               
>                                                               
>          
> 
> 
> 
> 
> 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.
> 
> > ----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 14.10.2006 07:50 
> > -----
> >
> >
> >
> >                       "Reinaldo Penno"
> >
> >
> >                       <rpenno@juniper.         To:
> > <[email-masked]>
> >
> >                       net>                     cc:
> > 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:
> > ===================
> >
> > 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.
> >
> 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 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).
> address/port would 
> > mean overriding any NAT proper behavior since the sequence numbers 
> > would surely differ and cannot be kept in sycn.
> >