Subject: RE: [midcom] Moving SPAN along

From: "Christian Huitema" <[email-masked]>
Date: Fri, 23 Aug 2002 09:11:03 -0700

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

There are a few issues with this draft. A first problem is one of
readability: there is a reference diagram, but the draft lacks a "model
of operation" section that would help the reader understand the proposed
mechanism -- for example, ladder diagrams of the TCP connection set up
and UDP connection set up. In the absence of such diagrams, it is hard
to quickly understand how the proposed scheme reacts, for example, to
network congestion. It is also hard to understand how the service can be
integrated with other services, such as SIP.

A second problem is one of scope. AFAIK, we already have a solution for
UDP, which is STUN. Do we need to standardize another UDP traversal with
SPAN?

A third problem is the security analysis. SPAN allows hosts located
behind a firewall to receive incoming TCP connections, possibly in
violation of the firewall policy; the possibilities for hackers are
enormous. Yet, this threat is not analyzed in the security section, and
no mitigation is proposed.

The last problem has to do with the connection model implied by SPAN.
While a STUN server can be put up at minimal cost, a SPAN server needs
to relay traffic. This is not very attractive, and may well explain the
lack of interest in the group.

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

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Aug 2002 11:59:28 +0100

Christian,

Thanks for your comments.

First of all, let me say that I consider the draft to be a starting point
rather than the final word.  I think other proposals have failed in this
area in the past because they tried to present a finished product.  I'm
hoping to try and evolve something as a group effort this time so I'm glad
that you are raising these issues.

Other comments inline...

Pete.

----- Original Message -----
From: "Christian Huitema" <[email-masked]>

> network congestion.

Sorry about that.  It seemed relatively straight forward to me, so I didn't
put ladder diagrams in.  I'll put some in a new draft.  In the mean time, as
a hint, the example messages pretty much follow the order in which messages
are sent and you should be able to mentally build up ladder diagrams simply
by looking at them.

> It is also hard to understand how the service can be

This could go in a future version.  However, there are many drafts out
there, such as midcom, that have very similar interaction so I figured this
was understood.

> UDP, which is STUN. Do we need to standardize another UDP traversal with

SPAN is intended to handle the symmetric case (+ a few other restricted
modes) that are not covered by STUN.

> no mitigation is proposed.

At first sight this does appear to be a problem.  HOWEVER, such connections
must be initiated by an internal party.  Also, even with outgoing
connections there is no guarentee about what you get back.  For example, you
can get all manner of things with HTTP and POP3.  In that light the
situation is not a risky as it first appears.

However, if it can be shown that this is much worse than the likes of HTTP
and POP3, then perhaps we should include ways that will not result in
firewall policy being violated.  Any suggestions?

> lack of interest in the group.

I'm glad this is the last problem :-)

I think this is a commercial issue rather than a standards issue.  In the
absence of direct communication, there are people that are prepared to
accept indirect communication rather than no communication.  I also see this
as a stepping stone solution where people can try out technology such as SIP
without major infrastructure changes.  Without it I think there are many
cases where SIP and the like won't take off.  So I think it's a case of
introducing some local sub-optimality in order to achieve some global
optimality.

It may be that the IETF decides that it is not bothered with such commercial
issues and is prepared to leave such matters to proprietry solutions.  Maybe
that is something we need to discuss.