Subject: [midcom] pre-midcom work item

From: Melinda Shore <[email-masked]>
Date: Fri, 21 Sep 2001 10:02:02 -0400

There has been considerable pressure for the IETF to come up
with a short-term approach to getting through firewalls and
NATs until midcom is available and widely deployed.  Because of
that we've been asked to add a quick-turnaround deliverable to
our charter.  The text of the charter addition will very likely 
be tweaked, but currently looks something like:

Ubiquitous deployment of midcom in all middleboxes could take many years.  In
the interim, a solution is needed that allows applications to operate in the
presence of midcom-unaware middleboxes. To support this, the midcom group
will develop or document a protocol or approach that allows clients to
indirectly obtain address bindings from midcom-unaware middleboxes, through
communications with server elements on the public side of the middlebox.  The
key goals for this effort are rapid delivery of a simple solution (since it
is an interim solution), consistency with the midcom framework, and
security.

The proposed milestone date for this is October 2001 (i.e. next month).

This would need to be accepted by the working group.  If there are
objections or concerns please let us know ASAP.

Thanks,

Melinda

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Sep 2001 11:04:59 -0400

> NATs until midcom is available and widely deployed. 

I fully support this idea.
However, I'd like to propose a slight change to the charter tweak:

> Ubiquitous deployment of a new middlebox control protocol would take many 
> years.  A short-term solution is needed to allow applications to operate 
> in the presence of existing middleboxes. To support this, the midcom 
> group will develop or document a protocol or approach that allows clients to
> is an interim solution) and security.

This means almost the same thing as the existing tweak, but it doesn't
presume that midcom will ever be widely deployed. 

Keith

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 21 Sep 2001 11:57:26 -0400 (EDT)

I do object adding this to the charter. This is the nail
that would break what the WG is set to deliver in the
first place. Interim solutions will be permanent
once deployed, to start with. Secondly, this introduces
new architectural constraints that is going to screw
the consensus achieved so far on the architecture draft.
Thirdly, this addition to the charter seems to be an
imposed ad-hoc solution rather than a charter requirement.
It also suggests that NAT is the only problem which far
from the truth.

The deployment argument of IKE/IPSec, IP6, MPLS didnt stop 
the WGs from developing those standards. Why should we be
the exception?

regards
Abdallah Rayhan

--- Melinda Shore <[email-masked]> wrote:
> Ubiquitous deployment of midcom in all middleboxes could 
> take many years.  In the interim, a solution is needed that 
> allows applications to operate in the presence of midcom-unaware 
> middleboxes. To support this, the midcom group will develop or 
> document a protocol or approach that allows clients to
> indirectly obtain address bindings from midcom-unaware 
> middleboxes, through communications with server elements on 
> the public side of the middlebox.  The key goals for this 
> effort are rapid delivery of a simple solution (since it
> is an interim solution), consistency with the midcom framework, 
> and security.
> 

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Scott Brim <[email-masked]>
Date: Fri, 21 Sep 2001 14:48:49 -0400

If you want to document "average current practice" that doesn't need a
working group, and I'd suggest that we stay out of it.  Let those who
are practicing document it.  

If you want something new, that's an agreed-on standard, it will take
more than 4 weeks.

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 21 Sep 2001 14:04:12 -0700 (PDT)

--- Melinda Shore <[email-masked]> wrote:
> communications with server elements on the public side of the middlebox.  

Sounds like, there is  a specific proposal behind this. Is this expected
to happen with no change to middlebox and a specific set of applications?
If so, what specific applications are you contemplating?
Why do you believe, the newer protocol protocol (as different from
MIDCOM protocol) is sooner to accomplish than MIDCOM? 

How do you suppose the Interim protocol will inteface with the middleboxes
to obatin current address bindings, impose newer address bindings, and do all 
the resource controlling (and payload manipulation) for the middlebox? 
Are you thinking SNMP MIBs? 

Would appreciate if you could throw more light on the thinking behind. 
Thanks.

regards,
suresh  
>                                                                          The

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 21 Sep 2001 17:43:03 -0400

I support the idea of doing this with the midcom WG. I don't think that
there is any other WG with participants from as wide a range of applications
interested NAT/firewall solutions.

The only existing work that I am aware of that matches the "approach that
allows clients to indirectly obtain address bindings from midcom-unaware
middleboxes" statement is:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt

Although this contains some SIP-specific sections, those dealing with an
endpoint learning its public address are applicable to the general NAT
problem. Although 4 weeks is an aggressive target, surely a proposal based
on the above document could be completed by the end of the year which is
certainly far in advance of any proposed midcom protocol.

I also agree with Dr. Rosenberg that this work item covers situations where
the ultimate midcom approach would not be appropriate.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Pyda Srisuresh" <[email-masked]>
To: "Melinda Shore" <[email-masked]>; <[email-masked]>
Sent: Friday, September 21, 2001 5:04 PM
Subject: Re: [midcom] pre-midcom work item

The

---

From: "Eliot Lear" <[email-masked]>
Date: Fri, 21 Sep 2001 12:08:00 -0700

This boils down to additional protocol development in the form of a
query to a server that returns some "netstat"-like information.

The best question you can ask is, "Is anyone from my address (whatever
that is) connecting to your transport X port Y?"  This will work only if
four things are true:

1.  The remote side runs an additional server to provide the
information;

2.  The process asking on the other side is coordinating ALL connections
of that type; and

3.  The various NATs that are gone through don't do NPAT such that
different IP addresses are used by the same host.

4.  Any reverse NATs also answer the question, as opposed to servers
behind them.

There is a security consideration here.  Others behind a NAT may ask the
same question and get a response.