Subject: [Sipping] WG Review: draft-ietf-sipping-nat-scenarios-07

From: "Mary Barnes" <[email-masked]>
Date: Tue, 21 Aug 2007 09:56:52 -0500

Hi folks,

This is to announce a Working Group Review on the following document:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.
txt

The review period will end on 10 Sept 2007 (original WGLC deadline). 

We had originally planned to start WGLC on the draft this week, but this
document has been on the back burner while ICE was being completed.  As
such, this document has not received much WG attention or review for a
while and isn't quite ready for WGLC.  However, we would still like to
start a detailed review of this document to determine what changes are
required to make it ready for WGLC, keeping in mind the original scope
and intent of the document.  We do have three reviewers that have
already volunteered: 
Guarav Kuhlshreshtha, Vijay Gurbani and Spencer Dawkins 

And, we would like to suggest that anyone else with an interest in this
topic to review the document at this time.  

Thanks, 
Mary 
SIPPING WG co-chair

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 22 Aug 2007 09:41:09 +0300

> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.

The Symmetric RTP reference is expired. It's RFC4961 nowadays.

But more importantly, [sipping-nat-scenarios] seems to misinterpret Symmetric 
RTP quite badly (or perhaps I interpreted Symmetric RTP very badly):

As far as I understand, Symmetric RTP [RFC4961] consists of RECEIVING TO and 
SENDING FROM the same UDP port. In other words, it overloads the meaning of 
the SDP m= line to not only specify the port you want to be sent media to, 
but also the port you will be sending media from:

  "A device supports symmetric RTP if it selects, communicates, and uses
   IP addresses and port numbers such that, when receiving a
   bidirectional RTP media stream on UDP port "A" and IP address "a", it
   also transmits RTP media for that stream from the same source UDP
   port "A" and IP address "a".  That is, it uses the same UDP port to
   transmit and receive one RTP stream."

As far as I understand [sipping-nat-scenarios], it defines Symmetric RTP as 
RECEIVING FROM and SENDING TO the same UDP port:

  "(...) This technique
   also requires intelligence by a client on the public internet as it
   identifies that incoming media for a particular session does not
   match the information that was conveyed in the SDP.  In this case the
   client will ignore the SDP address/port combination and return RTP to
   the IP address/port combination identified as the source of the
   incoming media.  This technique is known as 'Symmetric RTP' and is
   documented in [15]."

I believe some people refer to the [sipping-nat-scenarios] behavior 
as "address latching". In the real world, many media proxies and SBC 
implementations do that. That does not mean it is any good an idea.

First and backmost, this is misusing an RFC reference which is of course bad.
But, second and foremost, this is a pretty obvious security hole. With such 
a "promiscuous" manner of learning the other end's address, it becomes pretty 
trivial for any third party to hijack the media stream: they only need to 
guess your UDP port and send one dummy RTP packet to it.

I am very much against allowing this. Especially in a draft that does not have 
Security Considerations.

Another concern is the use of ANAT in for IPv4-IPv6 transition. I thought that 
was deprecated by ICE.

-- 
Rémi Denis-Courmont