Subject: Comedia Issues.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 29 Jun 2001 07:59:54 -0700

David Yon & myself where having offline discussions about the wording of how
the source information in the comedia draft may be used by applications.

The source information in the a=direction attribute is only used when two
applications are establishing logical bidirectional channels between them
(using two SDP complementary descriptions). The information encodes where a
connection will be originating from. 

Now existing SDP requires you to accept media from anywhere. I do not think
that comedia should be changing this. 

So I believe that the draft should be very clear that an application must
not enforce the source information supplied in the direction attribute when
accpeting connections and that this should only be used by residential
firewalls/NAT to open holes in the firewall (which was the reason the
information was originally added). This allows the RTP media to cross a
single (eg residential) NAT/firewall without modification or remapping of
the SDP fields - very useful! 

[Now David if I get your position wrong please correct me.] David believes
that the draft should not be so emphatic that the source information may not
be enforced by the application because in many cases there is no
NAT/firewall and thus gives a small amount of security to media. I realize
that many people want to solve the lack of security on RTP problems. Whilst
certain implementations may end up enforcing the information anyway,  the
draft should say that applications MAY NOT do this.

My reasons why it should not be inforced.
-	We are trying to preserve existing SDP behavior as much as possible
in comedia.
-	This enforcement prevents NAT/firewall traversal
-	This prevents early media. Ie, you won't be able to exchange media
until you have two SDP bodies.
-	This creates a race condition between signalling plane and the media
plane. The media may try to open a connection but it is refused because the
SDP with the source information has not been processed yet.
-	Source address information is easily spoofed anyway. 

So I am bringing this issue to the list. We would all like some RTP
"security" and I don't think comedia should change the model or you will
have all sorts of run-on effects (eg in SIP no early media or
music-on-hold). Thus, whilst the source information may be useful, I believe
the draft must be VERY SPECIFIC that an application MUST NOT enforce the
source information when accepting connections. Implementations may of course
decide to do so anyway but it should not encouraged in the draft.

I will be gone until Wednesdays so don't expect a reply from me until then.

Regards,

Robert.

---

From: David Yon <[email-masked]>
Date: Sun, 01 Jul 2001 10:00:59 -0400

Comments below.

At 10:59 AM 6/29/2001, Fairlie-Cuninghame, Robert wrote:

>David Yon & myself where having offline discussions about the wording of 
>how the source information in the comedia draft may be used by applications.
>
>(using two SDP complementary descriptions). The information encodes where 
>a connection will be originating from.
>
>Now existing SDP requires you to accept media from anywhere. I do not 
>think that comedia should be changing this.
>
>not enforce the source information supplied in the direction attribute 
>when accpeting connections and that this should only be used by 
>residential firewalls/NAT to open holes in the firewall (which was the 
>reason the information was originally added). This allows the RTP media to 
>cross a single (eg residential) NAT/firewall without modification or 
>remapping of the SDP fields - very useful!
>
>that the draft should not be so emphatic that the source information may 
>not be enforced by the application because in many cases there is no 
>that many people want to solve the lack of security on RTP problems. 
>Whilst certain implementations may end up enforcing the information 
>anyway,  the draft should say that applications MAY NOT do this.

My problem with this is that folks are reading too much into what the draft 
says.  It never, EVER says "enforce".  That is entirely outside the scope 
of what the source address is all about.  The point of the source 
address/port (SAP) is all about ENDPOINT IDENTIFICATION.

SAP is intended to address the topology there a TCP-based media endpoint is 
using the canonical TCP server style of accepting connections at a single 
port number.  The problem is that once you constrain the server to a single 
port, mapping connections to sessions becomes impossible without additional 
information.  There are two ways to solve this problem:

         a) Embed session identification information into the media stream, or
         b) Identify the session by the address/port of the remote endpoint.

Since (a) is incompatible with most media signalled by SDP, (b) is your 
only option.  That is the essence of why SAP is included in comedia.  It is 
"enforcement" only in the sense that certain topologies simply won't work 
unless SAP is signalled and is correct (i.e., not munged by N/PAT).

I suspect the fuss is about the topology that SAP was never intended to 
address: per-session, ephemeral TCP ports used at the server.  In this 
topology, SAP has no useful purpose whatsoever.  It is not necessary for 
session identification because the listening port has been reserved 
specifically for that session.  In the current state of the Internet (i.e., 
no SIP/SDP-aware ALP's) it provides no real leverage on residential 
gateways/firewalls.  Most N/PAT boxes pass outbound TCP connections 
today---SAP doesn't help or hinder that.  Firewalls will be just as 
difficult to get through, even more so in the ephemeral port topology 
because you can't pinhole a single TCP port.

So to address the ephemeral TCP port topology as it relates to SAP I 
suppose I can add a paragraph warning of the dangers of enforcement for 
that topology.  I submit that it is nonsensical to put apply such a warning 
to the fixed TCP port topology as it defeats the purpose of SAP.

>    * We are trying to preserve existing SDP behavior as much as possible 
> in comedia.
>    * This enforcement prevents NAT/firewall traversal

As for NAT/firewall, I'll repeat my mantra: COMEDIA DOES NOT SOLVE THE 
NAT/FIREWALL ISSUE.  At the end of the day, you need an ALP to solve the 
problem.  Without an ALP, comedia does two things:

         - For fixed-port TCP servers, the firewall problem is easier to 
address, but this
           ends up breaking N/PAT (because the SAP is incorrect).

         - For ephemeral-port TCP servers, the N/PAT problem is solved, but 
this
           ends up breaking firewalls (because you can't open a single port 
pinhole).

What you really, really want is an ALP that both:

         (a) assists by managing dynamic pinholes in firewalls/NPATs, and
         (b) rewrites SDP to make the addresses and ports correct

In either the ephemeral or fixed-port topology, SAP certainly provides 
much-needed information to an ALP.  But the bottom line is you really that 
ALP to make the NPAT/firewall traversal seamless.

>    * This prevents early media. Ie, you won't be able to exchange media 

I can't comment on early media as I haven't been following that in 
detail.  If correct, it sounds like early media is incompatible with 
fixed-port TCP servers.

>    * This creates a race condition between signalling plane and the media 
> plane. The media may try to open a connection but it is refused because 
> the SDP with the source information has not been processed yet.

The race condition issue raises a good point, although I'm not entirely 
convinced it is real.  I think in most sane media negotiations the side 
accepting the connection will already know the source information prior to 
connection setup.  In the case of SIP, this begs the question of whether it 
would be legal for the receiver of an INVITE to offer a direction:passive 
media line when the INVITE did not include a direction:both or 
direction:active line.

In either case, the problem is easily solved by having fixed-port TCP 
servers use a deferred-reject mechanism on inbound connections.  I.e., if 
an incoming connection occurs from an as-yet-unknown SAP, then the server 
needs to wait for some period in hopes that an ACK will arrive that 
contains the SAP of the unidentified connection.

>    * Source address information is easily spoofed anyway.
>
>
>music-on-hold). Thus, whilst the source information may be useful, I 
>believe the draft must be VERY SPECIFIC that an application MUST NOT 
>enforce the source information when accepting connections. Implementations 
>may of course decide to do so anyway but it should not encouraged in the draft.
>

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
[email-masked]

---

From: David Yon <[email-masked]>
Date: Wed, 04 Jul 2001 09:19:03 -0400

At the risk of sounding dense, it looks to me like your suggestion is a bit 
RTP-centric.  How would this map to T.38-over-TCP for example?

At 12:39 AM 7/4/2001, Jonathan Rosenberg wrote:

> > only option.  That is the essence of why SAP is included in
> > comedia.
>
>I think the nat fiasco has taught us that relying on IP addresses as
>identification is a bad thing. So, whilst I agree with (b), I wonder why we
>don't put the SSRC/cname in there instead? That has the advantage that it is
>globally unique (well, the cname is; the ssrc' may collide. But, you can
>detect this by notticing that the same ssrc came from two different IP
>addresses. Several ways to fix it...., but the problem goes away when the
>cname arrives. Just need to mandate that for unicast, you send a few RTCP
>right away to set the cname.). It provides endpoint identification that
>works through nats. It also allows us to <gasp> turn "RTP servers" (PSTN
>gateways, media servers, etc.) into traditional servers by defining a <gasp
>again> well-known port for RTP, and then demuxing on the SSRC/CNAME. Couple
>that with the symmetric RTP proposal, which has media sent back to the
>source IP where it came from. That means I could get RTP through firewalls
>by static configuration of a simple rule: allow outbound UDP to RTP-port
>(and allow media back to source addresses of outbound media).
>
>
>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 4 Jul 2001 11:46:09 -0400

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2001 9:19 AM
> To: Jonathan Rosenberg; Fairlie-Cuninghame, Robert; [email-masked]'
> Subject: RE: Comedia Issues.
> 
> 

Well, I'll admit that the suggestion is RTP centric. There is lots of
sessions that are RTP, and the issues you raise with traditional server
architectures apply there as well.

That said, I don't know T.38 really. Is there not some kind of ID carried
within the payload? Too late to add such a thing if not present?

-Jonathan R.

---

---

From: David Yon <[email-masked]>
Date: Wed, 04 Jul 2001 17:13:39 -0400

Yeah, yeah, go ahead and call my bluff... :-)  I have to admit I don't know 
whether T.38 has any room for session identification that can be used to 
map the media to the signaling, although I tend to doubt it.  Even if there 
was it would likely differ from your suggestion.

At any rate, I do like where you are going with this, and it's a worthwhile 
discussion.  In these days of firewalls, NATs, and hostile networks, I'm of 
the opinion that the only way to unambiguously associate a media stream to 
a session that's been signalled out-of-band is to embed information into 
the media itself.

That said, I would submit that it's a topic outside the scope of the 
comedia draft, which needs to address the current state of the world.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 6 Jul 2001 13:20:35 -0400

> Sent: Wednesday, July 04, 2001 5:14 PM
> To: Jonathan Rosenberg; Jonathan Rosenberg; 
> Fairlie-Cuninghame, Robert;
> [email-masked]'

The current world is full of NATs. Putting a solution in place now, which is
known to not work through NATs, is a mistake. 

-Jonathan R.
---

---

From: David Yon <[email-masked]>
Date: Mon, 09 Jul 2001 08:30:00 -0400

Yes, the world is full of NATs.  The world is also full of ALPs, which are 
currently the industry-standard way to address NAT-induced breakage.  It is 
NOT the case that comedia cannot work through a NAT, even in the absence of 
an ALP.  Refer to my earlier email that discusses network designs where 
comedia can, in fact, work through a NAT.

The issue is not whether NAT is a problem, but rather one of scope.  I 
submit again that this is not a comedia issue, on the following grounds:

         - There is nothing inherent about connection-oriented
           media versus connectionless media (i.e., RTP, UDP) that
           fundamentally changes the problem set.  If this issue
           is to be addressed it must be done in the appropriate
           context.

         - There is nothing in the comedia draft that introduces a
           new problem vis-a-vis NATs/Firewalls.

To attack this problem in a draft whose sole purpose is to define a way to 
describe connection-based protocols, would be a mistake.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 9 Jul 2001 06:24:22 -0700

Hi David,

>            is to be addressed it must be done in the appropriate

I disagree with this statement. There are two important differences (w.r.t
NATs/firewalls) for connection based media. The first is that
bidirectionality is guaranteed. For connectionless media, a NAT/firewall
will mostly have an asymmetrical response to packets; with connection-based
media, bidirectional media exchange is guaranteed (if a connection is
opened). Secondly and more specific to this argument, due to the first
property only one side needs to have a globally reachable address for
bidirectionality - only one side of the media-level connection needs to be
correlated with one of the transport address specified in the SDP's (for a
bidirectional application-level connection). 

Now the difficulty comes, as you say, for fixed-port servers where the
globally reachable transport address is shared between multiple sessions.
The difficulty being that the application can't associate the actual source
NAT address with the address in the SDP (w/o ALG's etc). I would point out
however that SDP does NOT specify the source address for the connectionless
case - the remote application is free to use any source address it chooses -
comedia should not change this. Thus I don't agree that source address
information can or should be used to provide the correlation for the
application. It can only be (reliably) provided in the media stream itself
unless each connection is assigned a unique port on the globally reachable
side. 

> describe connection-based protocols, would be a mistake.

If you provide a function in a draft, IMO the draft should describe why the
function is provided and how it is designed to be used (without being overly
restrictive) - especially when the function is fairly liable to
misinterpretation of purpose or use. 

The comedia draft goes beyond just describing the protocol by allowing the
source information to be included. If you were to remove this functionality
then I would agree with you that this argument is beyond the scope of the
draft. 

As this is included (and highly susceptible to mis-use causing a loss in
interoperability) then I think it's usage needs to discussed in the draft.

Robert.

---

From: David Yon <[email-masked]>
Date: Mon, 09 Jul 2001 09:55:08 -0400

>bidirectional application-level connection).

No: for bidirectional media, the problem is EXACTLY the same---that problem 
being that you can't trust the validity of IP addresses as specified in the 
SDP.  There is only a slight difference in how the symptoms present.  For 
bidirectional "traditional" (i.e., RTP-based) media, both sides must 
proffer addresses/ports as media destinations.   In connection-oriented 
media you can get by with only one side offering a destination.  So when 
Endpoint A is behind a NAT:

         - In comedia the Source Address/Port is wrong

         - In RTP the advertised destination is wrong

At the end of the day, the problem is that IP Addresses specified in the 
SDP packet aren't correct.  Comedia does nothing *fundamentally* different 
to this problem, it only shifts where some of the (potentially) faulty IP 
addresses appear.

>unless each connection is assigned a unique port on the globally reachable

It all depends on how the network is designed.  There ARE deployments where 
you can in fact assume correct addressing.  For those deployments where you 
cannot assume this, then yes you must be careful.

>interoperability) then I think it's usage needs to discussed in the draft.

That's fine, and I can spin a new version that discusses the problem more 
directly.  But that's different than Jonathan's statement, which implied 
that comedia shouldn't move forward until it works in all cases without the 
aid of an ALP.  On that basis we should be putting the brakes on 
draft-ietf-sip-rfc2543bis-03, which also doesn't work well with NATs.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Jul 2001 22:35:54 -0400

> Sent: Monday, July 09, 2001 9:55 AM
> To: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; [email-masked]'

And how is the server to know whether it is in one of these specially
designed deployments? We are designing protocols for an Internet, not an
intranet.

> draft-ietf-sip-rfc2543bis-03, which also doesn't work well with NATs.

Well, to be honest, if I had to do it over, I would have designed SIP from
the start to be nat friendly. Unfortunately, I don't have this luxury, and
so am forced to fix this through extensions. I am spending quite a bit of
time on doing exactly that.

> comedia can, in fact, work through a NAT.

<soapbox>
I disagree wholeheartedly. These days, people building new protocols that
want them used can't wait the 2-3 years it will take all NAT vendors to
implement the new protocol, not to mention the additional 2-3 years for
existing NATs that don't support it to get upgraded, followed by an
additional 2-3 years for upgrades to those nats as protocol extensions that
impact nat get standardized. Gnutella, for example, was designed to work
through nats from the get-go. I assure you that there would be no gnutella
today if they had designed a nat-unfriendly protocol and waited for Cisco,
Linksys, Netgear, Netopia, 2Wire, ...... to all get in line and implement a
gnutella ALG. The same is true for yahoo IM, AOL IM, net2phone's voip
protocol, and so on. In fact, the usage of ALGs, IMHO, is counter to the
end-to-end principle. Placing ALGs in NATs (which are routers), is akin to
saying "push application intelligence into layer 3, for every application
you might run". Is this not counter to the very notion of the Internet??
Rather, the end-to-end principle would argue for letting applications, in
end systems or network servers, learn about and deal with the
application-unaware nats that are present in the network. The midcom group
is all about that - moving application intelligence out of nats, and not
into them. The work I've been doing on sip traversal of residential nats is
doing the same - it argues that sip entities are ideally suited to figure
out how to traverse nats, not the other way around.
</soapbox>

That said, practically speaking, how will you get interoperability if the
source identification problem only "sometimes" works, and whether it works
depends on whether there is a nat somewhere else far away from the server?
Wouldn't you rather have a mechanism that allows you to deploy TODAY? I
assure you, I have been burnt bad with nats and sip, and I have sworn that I
will not make that mistake again....

Now, I am not advocating an RTP-specific mechanism. David has argued that
dealing with RTP doesn't belong in a draft on connection oriented media. The
problem is that the draft is really doing two separate things, (1)
describing how to use connection oriented media, and (2) describing how to
identify the source of media. Now, (2) is useful for single-port servers
that are using connection oriented media, but they are not the only users of
such a thing. I can name a few very useful applications of knowing the
source of media, and correlating that with signaling. So, I would aruge that
if the draft is covering (2), it should cover it fully and correctly, rather
than dealing with a narrow set of cases that we can't even assure
interoperability for.

One last point to note, is that even UDP/RTP can be connection-oriented. The
fact that connection-oriented protocols require only the server to have a
public address is a huge benefit for nat traversal, and one I am very
interested in. See:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

which specifies symmetric RTP. That draft even requests a new token to be
added to your draft. Don't add it though; a new version of the above is
coming out which doesn't need that. Keep a look out for it, it has some
pretty neat solutions in there that really finally  put sip nat traversal to
rest as a solved problem.

Now, I am really, really, really interested in the case where we have
connection oriented RTP/UDP with a single port server. In this case, I will
need that source identification for RTP/UDP. Why is that interesting? Well,
it allows firewall admins to set a single static rule for all voip to work
through it... its about time we had that.

-Jonathan R.

---

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 13 Jul 2001 14:00:35 -0700

If we really want to solve NAT traversal, we should also remove the
requirement to have RTP run on an even port, and RTCP on the next odd
port. In fact, we should run RTP and RTCP on the same port.

Note that there may be a generic way to deal with NAT, i.e. move to
IPv6.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 7:36 PM
> To: 'David Yon'; Fairlie-Cuninghame, Robert; Jonathan Rosenberg;
> [email-masked]'