James_Renkel | 1 Jul 20:13 2002
Picon

FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

All,

Sorry for the delay in noticing this.

This I-D was supposed to be announced to the midcom mailing list as well
as the general ietf-announce mailing list, but it wasn't.

Note that this I-D recommends that the midcom protocol requirements be
extended to require support in the midcom protocol for tunnels between
hosts and middleboxes. It's not that the use of tunnels would be
required, but that they would be supported by midcom if used. In our
experience, using tunnels is an extremely attractive alternative to
modifying applications or creating ALGs or agents to allow existing
applications to work correctly with NAT boxes.

The I-D also shows how traditional NAT can be supported in a host as a
tunnel would, and thus accrue the advantages of tunnels: no changes to
applications; no need for ALG or agent. The NAT function in the middlebox
remains unchanged, but a midcom server would need to be added to the
middlebox. But we were planning on doing that anyhow. :-)

Comments welcome and expected.

Jim

---------------------- Forwarded by James Renkel/MW/US/3Com on 07/01/2002
01:02 PM ---------------------------

Internet-Drafts <at> ietf.org <at> cnri.reston.va.us on 06/21/2002 06:37:01 AM

(Continue reading)

Keith Moore | 1 Jul 21:16 2002
Picon

Re: FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

The idea that tunnels can solve the NAT problem without changes to 
applications is critically flawed - the technique only works if
the application somehow has a tunnel to a location in the network
that is simultaneously accessible by all of that application's peers,
and if the application knows to use the interface/address associated
with that tunnel in preference to all other interface/address pairs
available to it.

It's certainly better than nothing, and probably better than other
things that Midcom has produced.  but it's not a general solution.

Keith
Christopher A. Martin | 1 Jul 21:43 2002

RE: FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

Tunneling also limitted to non-overlapping address space generally (at the
midcom side of the tunnel), and is not easily scaled....for multiple
overlapping address space even if individual MIDCOM solutions are
implemented to address this shortcoming...unless NAT or proxying is
implemented at the MIDCOM end to address this which means that we move the
problem closer to the agregate end.

I am rambling again... lets see what comes of it..I think it is a viable
alternative that has these limitations.

:^)

-----Original Message-----
From: midcom-admin <at> ietf.org [mailto:midcom-admin <at> ietf.org]On Behalf Of
Keith Moore
Sent: Monday, July 01, 2002 2:16 PM
To: James_Renkel <at> 3com.com
Cc: midcom <at> ietf.org
Subject: Re: [midcom] FWD: I-D
ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps

The idea that tunnels can solve the NAT problem without changes to
applications is critically flawed - the technique only works if
the application somehow has a tunnel to a location in the network
that is simultaneously accessible by all of that application's peers,
and if the application knows to use the interface/address associated
with that tunnel in preference to all other interface/address pairs
available to it.

It's certainly better than nothing, and probably better than other
(Continue reading)

Internet-Drafts | 2 Jul 12:33 2002
Picon

I-D ACTION:draft-stiemerling-midcom-simco-01.txt

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

	Title		: Simple Middlebox Configuration (SIMCO) Protocol 
                          Version 1.0
	Author(s)	: M. Stiemerling, J. Quittek
	Filename	: draft-stiemerling-midcom-simco-01.txt
	Pages		: 28
	Date		: 01-Jul-02
	
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, while still meeting
almost all requirements defined by the MIDCOM working group (see
[4]).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-01.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
(Continue reading)

James_Renkel | 2 Jul 20:33 2002
Picon

Re: Draft agenda


Melinda,

Please add the I-D "draft-renkel-middlebox-tunnels-00.txt" to the agenda.
I will limit the presentation to 5 minutes. Hopefully, we can limit the
discussion to another 5 or 10 minutes.

Thanks,

Jim

Melinda Shore <mshore <at> cisco.com> <at> ietf.org on 06/25/2002 11:07:29 AM

Sent by:  midcom-admin <at> ietf.org

To:   midcom <at> ietf.org
cc:
Subject:  [midcom] Draft agenda

I've appended a draft agenda.  Please let me know if
I've missed any agenda items, missed any relevant drafts,
or have gotten the revision numbers on drafts incorrect.
Note also that the Cordell SPAN draft hasn't yet been
posted.

Thanks,

Melinda

Middlebox Communication WG (midcom)
(Continue reading)

Melinda Shore | 2 Jul 20:50 2002
Picon

Re: Draft agenda

At 01:33 PM 7/2/02 -0500, James_Renkel <at> 3com.com wrote:
>Please add the I-D "draft-renkel-middlebox-tunnels-00.txt" to the agenda.
>I will limit the presentation to 5 minutes. Hopefully, we can limit the
>discussion to another 5 or 10 minutes.

We don't do presentations.  

Some process things:

1) The work of the IETF is accomplished on mailing lists.  Every
four months or so we try to meet face-to-face in order to resolve
things that could benefit from "lively" discussion and in order to
stress ourselves with insufficient sleep and too much heavy food
2) Meeting time is for discussion only - we don't do presentations
3) Nobody gets meeting time unless they've got specific issues
requiring resolution or for very short status updates (those updates
belong on the mailing list, too).  
4) The requirements document has been approved by the working group
and the IESG, and is now sitting in the RFC editor's queue.  We can't
go back and revisit it without changing the WG charter
5) We work by rough consensus and dashed hopes, which means that there
has to be *substantial* agreement among working group participants to
move something along, and even then it faces the possibility of being
rejected by the IESG
and most of all,
6) The work of the IETF is accomplished on mailing lists.

It's my understanding that what you'd like to see happen is for the
requirements and framework documents to be extended to include RSIP
tunnels.  You've proposed this several times and there doesn't seem
(Continue reading)

Melinda Shore | 2 Jul 21:06 2002
Picon

Status update

Here's where we are right now:
1) Pre-midcom:
   A) STUN: the next rev of the STUN draft should be appearing
      on the ietf-announce mailing list any time now and will be
      going into WG last call shortly after being posted
   B) SPAN-A: the design team is stalled due to a number of factors
      mostly related to participants' extra-midcom lives.  As a 
      result Pete Cordell's SPAN-A draft doesn't reflect the views
      of the design team - nevertheless, please consider it a 
      jumping-off point for further discussion, on the mailing list
      and possibly in Yokohama
2) Midcom:
   A) Protocol evaluation document: I think one more revision should
      do it.  Please review the document with a particular eye 
      towards what needs to be done to get it into and through WG
      last call
   B) Semantics: We have two semantics proposals, neither of which
      has received much discussion.  I've asked the authors whether
      or not they'll be able to resolve differences between the
      documents and come up with a single proposal; there are some
      substantial differences between the documents and it may not
      be a realistic approach.

Melinda
James_Renkel | 2 Jul 21:18 2002
Picon

Re: Draft agenda


Melinda,

I fully appreciate that the overwhelming majority of the work of IETF
working groups is done via mailing lists. I participate in them as much
as my time permits.

I requested presentation time because that seemed to be the way that
other working groups that I participate in work. Their meeting agendas
give specific amounts of time to presentation of issues that were raised
in e-mail discussion of I-Ds. I did not intend to completely represent
the tunneling idea, but simply to summarize the admittedly scant e-mail
discussion that there has been and try to resolve the issue of whether
or not the MIDCOM protocol should include support for tunnels.

I agree that there has not been much discussion of this, but my reading
of what discussion there has been is that it's split pro and con. I
thought this justified a few minutes of meeting time, but I will defer
to your opinion that it does not.

Jim

Melinda Shore <mshore <at> cisco.com> <at> ietf.org on 07/02/2002 01:50:28 PM

Sent by:  midcom-admin <at> ietf.org

To:   James Renkel/MW/US/3Com
cc:   midcom <at> ietf.org
Subject:  Re: [midcom] Draft agenda

(Continue reading)

Internet-Drafts | 3 Jul 12:30 2002
Picon

I-D ACTION:draft-ietf-midcom-protocol-eval-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the IETF.

	Title		: Middlebox Communications (MIDCOM) Protocol Evaluation
	Author(s)	: M. Barnes
	Filename	: draft-ietf-midcom-protocol-eval-02.txt
	Pages		: 33
	Date		: 02-Jul-02
	
This document provides an evaluation of the applicability of SNMP, 
RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary 
of each of the proposed protocols against the MIDCOM requirements 
and MIDCOM framework is provided.  Compliancy of each of the 
protocols against each requirement is detailed. A conclusion 
summarizes how each of the protocols fares in the evaluation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-02.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-ietf-midcom-protocol-eval-02.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
(Continue reading)

Jonathan Rosenberg | 5 Jul 20:27 2002

update to STUN posted

Folks,

I managed to get an update to STUN in before the I-D deadline. It should 
appear in the archives shortly. Until it does, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-midcom-stun-01.txt

The biggest change is the security stuff, which is now based on a 
one-time-password exchange over TLS. It does request and response 
integrity checks with an HMAC-SHA1 using that password.

Comments welcome.

-Jonathan R.
--

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen <at> dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

Gmane