Subject: [midcom] Moving SPAN along

From: Melinda Shore <[email-masked]>
Date: Fri, 23 Aug 2002 09:29:03 -0400

We're continuing to fail to make progress on SPAN and we
really do need to get serious about moving it along.  Pete's
draft has received extraordinarily little comment.  Please
have another look at it and post comments to the mailing
list.  The URL is
http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt.

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 19 Aug 2002 13:47:43 -0700

I have not said much on this draft because it is impossible to know where to
start on all the things I see needing changes.

However, lets get a few high level issues straitened out before we even look
into the draft.

1) The media packets get bigger. G.729 packets have 12 bytes of payload
data - any addition to this significantly increases the bandwidth usage of
the protocol. If I had any interest in increasing the size of this stuff
there are other protocols I could use such as PPP, RSIP whatever. <bold> I
don't think we should be doing a solution in this WG that increases the size
of the media packets being relayed </bold> If I did I would go down the path
of encapsulated media packets, the IP in IP described with SDP would likely
be the route that I would want to take.

2) The arbitrary TCP tunneling stuff eliminates the ability of the FW admin
to assert policy - which is something we agreed we would not do

3) This draft is needlessly complex resulting in a more confusing security
situation.

Cullen

ps As a side note, every day we discuss this, more NATs become port
restricted so that games will work through them - at times I wonder if
something beyond STUN is needed.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Melinda Shore
> Sent: Friday, August 23, 2002 6:29 AM
> To: [email-masked]
> Subject: [midcom] Moving SPAN along
>
>

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Aug 2002 12:52:54 +0100

Cullen,

Thanks for your comments...

Pete.

----- Original Message -----
From: "Cullen Jennings" <[email-masked]>

> start on all the things I see needing changes.

At the beginning :-)

> be the route that I would want to take.

By my calculation, the extra 8 bytes of header amounts to about 15% extra
traffic.  This seems a small amount compared to the 433% overhead introduced
by IP/UDP/RTP.  I think the header information adds benefit.  It's more
stateless and more general.  But if people are really worried about the
overhead, it could be removed.

> to assert policy - which is something we agreed we would not do

I'm confused.  There's no TCP tunnelling in the draft.

> 3) This draft is needlessly complex resulting in a more confusing security

A bit of a sweep all statement.  Please send in specifics on which bits are
needless and we can work out how to remove them.

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 28 Aug 2002 09:53:56 +0100

----- Original Message -----

> be the route that I would want to take.

As a result of banging numbers into my calculator I forgot to mention in my
previous e-mail that IP over IP or PPP over IP typically won't get through
NAT, especially NAPT.

Even if they could, IP over IP would involve a much greater overhead, and
PPP would involve numerous round-trips for negotiation etc.  Neither of
these are desirable.

RSIP doesn't work through many types of NAT, and also is typically
implemented as part of the OS rather than the application.  The latter
creates a dependency on unknown third parties that is not compatible with a
short term solution.

Pete.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Aug 2002 10:54:00 -0400

At this point there seems to be very little support for
continuing to work on SPAN.  The question is whether or not
the problem of traversing symmetric NATs is sufficiently
compelling.  If it is we need to continue; if not we can
consider dropping the deliverable.  Let's try to resolve
this question over the next few days.

Melinda

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 28 Aug 2002 17:22:07 +0100

There is also the issue of providing traversal for TCP.

This is however more of an issue for H.323 and other similar protocols
(possibly including some IM scenarios) than SIP.

Pete.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Aug 2002 21:41:07 -0400

I think the problem is important. Note that, you need something in the 
TURN/SPAN area even for full cone NAT. There are cases where two users 
are behind a full cone NAT, but the SAME full cone NAT. STUN, in this 
environment, would require the NAT to receive a packet on the inside, 
addressed to a public IP corresponding to another one of its bindings. 
Most NATs apparently do not properly turn the packet around to the 
private address for the second binding. This case can be detected with 
STUN, but it cannot be fixed with STUN.

-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