Subject: [midcom] Protocol proposal interest level check

From: Archie Cobbs <[email-masked]>
Date: Thu, 3 Jul 2003 15:11:58 -0700 (PDT)

Hello,

I'm new to this working group and have joined the mailing list
because the MIDCOM charter addresses the problem area that I'm
working in and seems to clearly identify and describe the issues.

I've scanned the archives and read the MIDCOM RFC's and drafts,
however it takes a little digesting so please pardon my general
ignorance.

I'd like to guage public sentiment on this mailing list for a
new protocol proposal.

I've been working privately on designing a simplified "MIDCOM-ish"
protocol that satisfies only a subset of the requirements in RFC
3304. Although it is far from the ultimate goal of MIDCOM, my ideal
would be to get it reviewed and published via this working group
as a sanctioned "baby step" protocol. The hope is that this protocol
could find a niche similar to STUN, i.e., a protocol that solves a
small but important problem in a simple and easily implemented way.

The basic idea is that an internal host can describe and request
"sessions" to be created in a middlebox and have the middlebox
return the externally visible form of those sessions (i.e., the
publicly visible NAT'd IP, port, etc.) and open firewall holes if/as
necessary. A "session" is what you might expect, e.g., in the case
of TCP it would be <proto, local IP, local port, remote IP, remote
port>.

The protocol would be designed to be very simple and support only
the above operation. It would however allow "sessions" in protocols
other than TCP and UDP, support the notions of session timeout and
wildcards (e.g., for NAT cones), and allow for future extensions.
The IP address of the middlebox would be configured in the host via
DHCP option or static config (this is really a separate issue).
The current (semi-lame) working name is PANT - ProActive NAT Traversal.

If this working group would be interested in pursing this kind of
protocol I would be happy to do the grunt work of writing up the
first draft, etc., in exchange for benefitting from the collective
wisdom represented here. Of course there are no guarantees that
we'll all agree but I'd like to at least get a sense of the general
sentiment out there for the idea.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *    Halloo Communications    *     http://www.halloo.com

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 03 Jul 2003 18:36:06 -0400

What you describe is the original midcom proposal.  Our
charter required us to start with adopting existing IETF
protocols, which is what we're currently doing.  In the
meantime Microsoft organized an industry consortium to
develop a different, more timely (!!) midcom protocol,
called UPnP.  How does your protocol differ from UpnP?

Melinda

---

From: Archie Cobbs <[email-masked]>
Date: Thu, 3 Jul 2003 16:14:31 -0700 (PDT)

> called UPnP.  How does your protocol differ from UpnP?

Thanks for the background info.

I'm not very familiar with UPnP (surfing the web now...). It seems
more heavyweight than what I had in mind. On the other hand, it
appears to have some momentum behind it.

I'm still interested in hearing people's opinions on my idea
(pos or neg) and also on UPnP.

Thanks,
-Archie

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 04 Jul 2003 10:35:13 +0200

Hi Archie,

nice idea and sounds good, but have tried to take a look into SIMCO?
SIMCO is a MIDCOM protocol that is in full compliant with the MIDCOM 
semantics. The currently available version will be adapated soon to the 
latest changes of the semantics. The protocol can do configuration of 
packet filter firewalls and any kind of NATs.

Would be nice to hear your comments.

Cheers
Martin

P.S.:Here is the annoucement of SIMCO:

Date: 05 March 2003 06:30 -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-stiemerling-midcom-simco-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Simple Middlebox Configuration (SIMCO) Protocol
                          Version 2.0
	Author(s)	: M. Stiemerling, J. Quittek
	Filename	: draft-stiemerling-midcom-simco-03.txt
	Pages		: 20
	Date		: 2003-3-4
	
This memo specifies the Simple Middlebox Configuration (SIMCO)
protocol for configuring Network Address Translators (NATs) and
firewalls dynamically to create address bindings and open pinholes.
NATs and firewalls are a problem for applications using voice and
video streaming, such as IP telephony, because they need to establish
voice or video channels dynamically. The SIMCO protocol allows
clients to send requests for this purpose to serving NATs and/or
firewalls.  The protocol is designed to provide a simple and basic
solution that can easily be implemented and used. The protocol meets
all requirements defined by the MIDCOM working group (see [4]) and it
implements the MIDCOM semantics [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-stiemerling-midcom-simco-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-stiemerling-midcom-simco-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---------- End Forwarded Message ----------

--On Thursday, July 03, 2003 15:11:58 -0700 Archie Cobbs 
<[email-masked]> wrote:

| Hello,
|
| I'm new to this working group and have joined the mailing list
| because the MIDCOM charter addresses the problem area that I'm
| working in and seems to clearly identify and describe the issues.
|
| I've scanned the archives and read the MIDCOM RFC's and drafts,
| however it takes a little digesting so please pardon my general
| ignorance.
|
| I'd like to guage public sentiment on this mailing list for a
| new protocol proposal.
|
| I've been working privately on designing a simplified "MIDCOM-ish"
| protocol that satisfies only a subset of the requirements in RFC
| 3304. Although it is far from the ultimate goal of MIDCOM, my ideal
| would be to get it reviewed and published via this working group
| as a sanctioned "baby step" protocol. The hope is that this protocol
| could find a niche similar to STUN, i.e., a protocol that solves a
| small but important problem in a simple and easily implemented way.
|
| The basic idea is that an internal host can describe and request
| "sessions" to be created in a middlebox and have the middlebox
| return the externally visible form of those sessions (i.e., the
| publicly visible NAT'd IP, port, etc.) and open firewall holes if/as
| necessary. A "session" is what you might expect, e.g., in the case
| of TCP it would be <proto, local IP, local port, remote IP, remote
| port>.
|
| The protocol would be designed to be very simple and support only
| the above operation. It would however allow "sessions" in protocols
| other than TCP and UDP, support the notions of session timeout and
| wildcards (e.g., for NAT cones), and allow for future extensions.
| The IP address of the middlebox would be configured in the host via
| DHCP option or static config (this is really a separate issue).
| The current (semi-lame) working name is PANT - ProActive NAT Traversal.
|
| If this working group would be interested in pursing this kind of
| protocol I would be happy to do the grunt work of writing up the
| first draft, etc., in exchange for benefitting from the collective
| wisdom represented here. Of course there are no guarantees that
| we'll all agree but I'd like to at least get a sense of the general
| sentiment out there for the idea.
|
| Thanks,
| -Archie
|
| __________________________________________________________________________
| Archie Cobbs     *    Halloo Communications    *     http://www.halloo.com
|
| _______________________________________________
| midcom mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/midcom

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Archie Cobbs <[email-masked]>
Date: Sun, 6 Jul 2003 16:55:02 -0700 (PDT)

> packet filter firewalls and any kind of NATs.

Thanks for the pointer, I'll take a look.

Perhaps this draft should be added to the working group home page:

 http://www.ietf.cnri.reston.va.us/html.charters/midcom-charter.html

Thanks,
-Archie