Subject: [midcom] WG scope/deliverables

From: Randy Turner <[email-masked]>
Date: Tue, 23 Jan 2001 01:51:09 -0800

I'm assuming that the model of an RSIP client and server would be an example
of middlebox communication, per the charter. And further, that the real
deliverable for this working group
would be a capability that would superset RSIP and provide a more generic
model for middlebox policy interrogation, including more sophisticated trust
models. Is this correct?  

Thanks!
Randy

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Randy Turner <[email-masked]>
Date: Wed, 31 Jan 2001 00:38:17 -0800

The charter seems to indicate much more than just enabling inbound traffic,
but I'll wait and see what falls out for requirements. I think "enabling
inbound traffic" is the first easily recognizable, enumerated requirement
I've heard.  I personally didn't have much of a problem with RSIP, although
it did put a large burden on existing client stacks. As a vendor that would
have to implement the server side of this equation, we saw RSIP
functionality as pretty straightforward.

A lot of good information and useful techniques and knowledge are available
from the RSIP group. So I would ask that, if the goals of this effort are a
proper subset of what RSIP provides, then we should probably reuse the ideas
instead of reinventing them again. Of course we could recast these
techniques in a different transport methodology, but alot of the concepts of
operation would be the same.

Randy

-----Original Message-----
From: Bernard Aboba
To: Randy Turner; [email-masked]
Sent: 1/30/01 11:47 PM
Subject: RE: [midcom] WG scope/deliverables

>the real deliverable for this working group would be a capability that
>would superset RSIP

Keep it simple, please. RSIP's major failing was that it tried to do too
much, not too little. The world is littered with the bones of
under-deployed
firewall traversal solutions. The crux of the problem is enabling
inbound
traffic. Let's solve that with as little extraneous baggage as possible.

---

From: John Lazzaro <[email-masked]>
Date: Wed, 31 Jan 2001 17:04:43 -0800

> Christian Huitema writes ...

> The peer-to-peer application require that the host behind the NAT can
> publish an IP address and a port, and receive TCP connections to that
> port.

Please, don't forget UDP as well -- I've had success in my own projects
using the Activision techniques described in RFC3027 which are aimed
as UDP, and it would be nice to see UDP-oriented techniques of this
nature be a part of this WG ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

---

From: [email-masked] (Sean Doran)
Date: Thu, 1 Feb 2001 05:26:56 +0100 (CET)

[moved off main ietf list, and Cc list pruned]

Christian Huitema writes:

| The point being that if you have an arbitrary bunch of firewalls and
| NATs between any two points, then you are forced into telephone-like
| "call set-up" scenarios, which don't really scale to large groups,
| specially when the application consists of sporadic messages to
| arbitrary destinations. 

So the middle box joins a multicast group and forwards on behalf
of the things behind it messages to the group, and messages from
the group.  In the messages the source and set of receivers will
have to have some indication of identity of the sender/receiver
set.  This identity is the "who"; the "where" part is "behind middle box",
which is the visible source address in the IP multicast header.

Or, if we presuppose an IPv4 multicast scheme that is more single-source-ish,
in the sense of groups with one sender and maybe millions of receivers,
we can build our own private MBONE among middleboxen and do native
multicast on the "outside" of the Internet core, keeping the S,G state
hidden from it, by putting unicast tunneling into the middleboxen.

There are many other ways to skin the cat of many-host 
messaging, even with huge groups, infrequent senders, untrustworthy
or mangled source topological locators, sub-grouping (i.e., pruning
out listeners who don't want or can't use certain messages), a
desire for unicast communication triggered by a many-host announcement,
and so forth.  USENET is an excellent proof of all of this, thanks
to the Instant Propagation Party of some years past.

You might point to the difficulty of sending to some party that
does not know they should be listening for the transmission, and
thus have not "tuned-in" to the multicast group (or newsgroup or ...).
Tricky, but, arbitrary messages sent to destinations that one might
not be able to reach directly, perhaps even because a gateway
must be used, was solved for SMTP by using MX RRs.    An ALG RR
analogous to an MX RR but more general than for "M"ail proxying,
is an obvious solution, although I would hope someone smarter could 
think up a creative approach that revs neither BIND and equivalents
nor the contents of the DNS.

	Sean.