Subject: RE: [midcom] pre-midcom work item

From: "Christian Huitema" <[email-masked]>
Date: Fri, 21 Sep 2001 09:25:10 -0700

I support inclusion of this item in the charter. It can be done in
parallel with the deployment of Midcom. While it is true that NAT are
not the only problem we have to solve, NATs, and especially the "$200
box" variations, are a real problem in the deployment of many
applications. In fact, proprietary solutions already exist and are
already deployed; having a standard would ease deployment of compatible
software by multiple vendors.

-- Christian Huitema

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 8:57 AM
> To: Melinda Shore; [email-masked]
> Subject: Re: [midcom] pre-midcom work item
> 
> 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
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 21 Sep 2001 11:44:49 -0500

Hi all,

For clarification, is this work that you're proposing as a result of the
adhoc session on Firewall Traversal in which it was agreed that there is a
need for a pre-midcom "Average Current Practice"?  Details of that meeting
are at:
http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html

If so, then I would agree to the need for this work to happen. However, it
would seem that we would a separate mailing list, etc., so as not to detract
from the currently chartered work.

Regards,
Mary H. Barnes
[email-masked]
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Friday, September 21, 2001 11:25 AM
To: Abdallah Rayhan; Melinda Shore; midcom
Subject: RE: [midcom] pre-midcom work item

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 21 Sep 2001 09:52:42 -0700

The discussions were actually held in the AVT and MMUSIC working groups.

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, September 21, 2001 9:45 AM
To: Melinda Shore; midcom
Cc: Christian Huitema; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item

Hi all, 

For clarification, is this work that you're proposing as a result of the
adhoc session on Firewall Traversal in which it was agreed that there is
a need for a pre-midcom "Average Current Practice"?  Details of that
meeting are at:

If so, then I would agree to the need for this work to happen. However,
it would seem that we would a separate mailing list, etc., so as not to
detract from the currently chartered work.

Regards, 
Mary H. Barnes 

-----Original Message----- 
From: Christian Huitema [mailto:[email-masked]] 
Sent: Friday, September 21, 2001 11:25 AM 
To: Abdallah Rayhan; Melinda Shore; midcom 
Subject: RE: [midcom] pre-midcom work item 

-- Christian Huitema

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Sep 2001 12:53:36 -0400

Mary,

Yes. This is the same problem that was discussed at that adhoc.

I will note that there were maybe 30 people at that adhoc, with nearly
unanimous agreement to proceed with a solution.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Friday, September 21, 2001 12:45 PM
To: Melinda Shore; midcom
Cc: 'Christian Huitema'; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item

Hi all,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Sep 2001 13:00:27 -0400

There are many aspects to the total solution for voip.

We need SDP extensions to support non-adjacent RTP/RTCP ports. That has been
agreed to in mmusic.

We need RTP to allow for non-adjacent RTP/RTCP ports. That has been agreed
to in AVT.

We need SIP itself to work properly through nats, even without a pre-midcom
protocol (not the media, just SIP). That has also been agreed to as a sip
working item.

To support low latency RTP even in the face of symmetric NATs, we need
"symmetric RTP". Thats nothing more than usage of non-adjacent RTP/RTCP
ports when you get down to it, plus some SDP signaling enhancements. We
already have those in mmusic through the comedia draft.

We need a protocol to allow a client in a natted residence or enterprise to
learn about the presence of nats between it and the public internet, and to
obtain the bindings created by the nat in order to place them into SDP. That
is the piece that was discussed during the adhoc, and that is the proposed
charter item. 

We need a document that ties the whole thing together, showing how one could
use sip, SDP extensions, and the new reflector protocol to build a variety
of different voip configurations that work with nat. That is the purpose of
the agreed upon sipping charter item (number 5 on
http://www.softarmor.com/sipping/sipping-charter-draft.htm).

-Jonathan R.

---

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, September 21, 2001 9:45 AM
To: Melinda Shore; midcom
Cc: Christian Huitema; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item

Hi all,

---

From: Randy Turner <[email-masked]>
Date: Fri, 21 Sep 2001 10:28:38 -0700

Hi Jonathan,

In one your responses below, you are suggesting that MIDCOM would not solve
the problem that this interim work would solve. So these two solutions are
orthogonal? That would imply that MIDCOM would not supersede this work at
some point, rather *both* would be needed.

> the WGs from developing those standards. Why should we be

<No one is saying that it should not be deployed. Full steam ahead. We
need
midcom, and that hasn't changed. The fact is that midcom can't fully
solve
our problems.>

Just looking for clarification,

Thanks!
Randy

-----Original Message-----
From: Jonathan Rosenberg
To: 'Abdallah Rayhan'; Melinda Shore; [email-masked]
Sent: 9/21/01 9:50 AM
Subject: RE: [midcom] pre-midcom work item

I **>STRONGLY<** support the inclusion of this item into the charter.

Just so people are crystal clear on what this is talkign about, it is
referring to the kind of protocol described in:

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

Specifically, the "reflector" protocol described there. I have split
this
protocol out as a separate, sip independent document, and am working
with
some colleagues to finish it up. Expect to see a draft shortly.

Responses to Abdallah inline:

> Sent: Friday, September 21, 2001 11:57 AM
> once deployed, to start with. 

That is only true when the motivation to upgrade is not there. However,
the
solution we are talking about here does not solve the full scope of
problems
midcom is solving. In particular: 

* it does not address firewall control
* it has no story around fault tolerance
* it doesn't address twice nat
* it won't work properly in networks with multiple natted egress points

As such, the proposed addition is really targeted at the residential and
small enterprise markets. I think that it will never be acceptable to
carriers or large enterprises, which need a real midcom solution.

These particular markets are also problematic because its not just an
issue
of when midcom is finished. The administrator of the nat, in many cases,
is
NOT the one who is responsible for delivery of applications. As such,
even
if a midcom nat is available, these administrators will not be incented
to
upgrade, since there is no reason. The case I always use is that of an
airport Internet lounge, which has a nat. The lounge provides
connectivity,
and thats it. They don't care, and may not even know, about apps like
VoIP.
They will not be incented to upgrade those nats to midcom enabled ones.
We
need solutions for those kinds of scenarios.

> Secondly, this introduces

How is that?

> It also suggests that NAT is the only problem which far

Agreed, which is why midcom remains important. This addition will help
us
deal with very very real, very very problematic retail deployment
scenarios
which are currently on hold because of NAT. 

> the WGs from developing those standards. Why should we be

No one is saying that it should not be deployed. Full steam ahead. We
need
midcom, and that hasn't changed. The fact is that midcom can't fully
solve
our problems.

Its also worth noting that there are already solutions being deployed
today
that play the role of the proposed addition. Those are all proprietary
and
not interoperable. Let us not let that continue.

-Jonathan R.

---

---

From: Melinda Shore <[email-masked]>
Date: Fri, 21 Sep 2001 13:24:03 -0400

At 11:44 AM 9/21/01 -0500, Mary Barnes wrote:
>For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? 

Not directly.  There's been a lot of pressure for something
interim and ugly across several working groups, and the work
to do this will be spread across several working groups.  The NAT
portion has been sent to us in order to ensure consistency
with the midcom framework.

Melinda

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 21 Sep 2001 13:06:00 -0500

Jonathan and Christian,

Thanks for the clarifications on the relation of this work to other WGs.  I
fully support the need to develop an "Average Current Practice" solution for
this ASAP (and would agree to doing this in the mainstream MIDCOM WG).  

I just want to ensure that my comment to take this to a separate list was
not mis-interpreted to reflect lack of support. My proposal to take this to
a separate mailing list was really an attempt to solve the concerns that
were raised that this would be deemed disruptive to the current WG
activites.  

Mary.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, September 21, 2001 11:54 AM
To: Barnes, Mary [RICH1:B602:EXCH]; Melinda Shore; midcom
Cc: 'Christian Huitema'; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item

Mary,

-Jonathan R.

---
  
-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Friday, September 21, 2001 12:45 PM
To: Melinda Shore; midcom
Cc: 'Christian Huitema'; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item

Hi all,

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 21 Sep 2001 17:24:40 -0700

The design goal is that any interim solution will be fully transparent
to the existing NAT, i.e. will not require any participation of the NAT,
or any change to the NAT. That, alone, makes it much more likely to be
deployed in a very short time frame.

-- Christian Huitema

> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 2:04 PM
> > 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.
> 
> 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
> > 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
> >
> >
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
> Messenger. http://im.yahoo.com
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Sep 2001 21:20:09 -0400

> From: Scott Brim [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 2:49 PM
> To: [email-masked]
> 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.

I think what we want is an agreed upon standard. It can be done quickly,
providing the following is true:

1. only people truly interested in seeing it completed in a timely fashion
participate
2. a document that is 90% complete is chosen as the basis for moving
forward, and peoples comments are delta changes from there, not fundamental
arguments about its approach or feature set.

I will be submitting a specification shortly that I think fits the bill; its
a distillation of draft-rosenberg-sip-entfw-02 with input from others who
have thought similarly. 

The relative simplicity of this protocol compared to lots of other things
makes this a conceivable plan. I don't know about 4 weeks, but certainly in
a matter of 1-2 months or so (i.e., before the next ietf) is feasible.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Sep 2001 21:27:02 -0400

> From: Randy Turner [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 1:29 PM
> To: 'Jonathan Rosenberg '; ''Abdallah Rayhan' '; 'Melinda Shore ';
> [email-masked] '

Its not a technology issue, so its hard to say. This protocol solves the
cases where there is a nat which cannot (or the administrator will not)
upgrade to support midcom, or allow it. How long will it be the case that
there are nats which are not midcom enabled, or which are midcom enabled but
this capability is disabled? I don't know. 

From a purely functional perspective, I don't think there is anyting in this
new protocol that midcom cannot do. In fact, midcom does quite a lot more.
Arguably, this more extensive functionality in midcom makes its security
concerns more complex, which may make it ultimately hard to deploy in things
like residential nats, where managing such security policies is hard. Since
the new protocol can't "create" nat bindings to anything except the client
that asked for the binding, the security implications are much less and
easier to manage.

> Just looking for clarification,

Hope the above answers the question.

-Jonathan R.

---

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 22 Sep 2001 07:37:46 -0700

So,

a few days ago our chair was saying rather emphatically we were not going to
work on any MIDCOM protocol. Now we are going to work on a pre-midcom
protocol which is highly questionable and might (no matter what some people
say) preclude the development of MIDCOM altogether. So the solution might be
not for carriers now, then after the first release we make some adjustments
here and there and carry on...and bye bye midcom. 
 
Moreover what happened to the IETF's rough consensus? This seems to me more
like a dictatorial regime than anything else.  

So, only people that agree with your ideas can participate (number 2 below)
? And only people which is "truly interested in seeing it completed in a
timely fashion"? Timely for whom? 

IMO this needs much more discussion even if it doesn't fit someone's
"agenda".

-RP

---

From: "Ram Dantu" <[email-masked]>
Date: Sat, 22 Sep 2001 11:16:23 -0500

Jonathan,

In the London Adhoc meeting, we are supposed to have a 
mailing list for NAT & FW traversal. Do we have one ?
If so, can we please advertise on the midcom list.

Thanks
Ram Dantu Ph.D.,
Netrake Corporation
3000 Technology Drive, #100
Plano, Texas, 75074.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, September 21, 2001 8:27 PM
To: 'Randy Turner'; Jonathan Rosenberg; ''Abdallah Rayhan' '; 'Melinda
Shore '; [email-masked] '
Subject: RE: [midcom] pre-midcom work item

Its not a technology issue, so its hard to say. This protocol solves the
cases where there is a nat which cannot (or the administrator will not)
upgrade to support midcom, or allow it. How long will it be the case
that
there are nats which are not midcom enabled, or which are midcom enabled
but
this capability is disabled? I don't know. 

From a purely functional perspective, I don't think there is anyting in
this
new protocol that midcom cannot do. In fact, midcom does quite a lot
more.
Arguably, this more extensive functionality in midcom makes its security
concerns more complex, which may make it ultimately hard to deploy in
things
like residential nats, where managing such security policies is hard.
Since
the new protocol can't "create" nat bindings to anything except the
client
that asked for the binding, the security implications are much less and
easier to manage.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Sep 2001 01:59:08 -0400

> From: Eliot Lear [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 3:08 PM
> To: [email-masked]; Melinda Shore
> 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:

I'm not sure I follow. How does this help with nat traversal?

Let me give a little detail on the kinds of things this new charter item is
talking about. There are variations on the solutions, but there are a few
common themes that can convey the basic idea.

Consider a client that is behind a nat. It sends a request from a local
socket, destined for some public server on the Internet. This server is
hardly more than an echo server. It receives the request, and examines the
source IP/port of that request. It places that information into the body of
a response message that is sent back to the source IP/port where the request
came from. The client now has the public address of the binding created by
the nat for that request. If the nat is a "full cone" variant (the
recommended type described in
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt),
any host on the public internet can send to this address/port, and it will
arrive on the socket used to send this "echo" packet. So, the client uses
that address in its application protocol (i.e., embedding it in the SDP of a
SIP INVITE), and it is now capable of receiving media on it.

Effectively, the client allocated a binding from its nat. It did that, not
by talking TO the nat, but by talking THROUGH the nat. 

HTH,

Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Sep 2001 23:59:47 -0400

> Sent: Friday, September 21, 2001 9:20 PM
> To: 'Scott Brim'; [email-masked]

I'd like to make an apology for my statements above.

I did not mean in any way to imply any sort of dictatorial or totalitarian
directions for the group, nor did I mean to imply that any document I would
submit would have to be accepted or would be 90% done. My statements above
do come across as seeming to imply that, and I am sorry.

All I meant to say is that groups can make rapid process when there is
strong consensus on a general approach, with a document that describes that
agreed upon approach.  Nothing more.

As always, the decision to move forward is based on the consensus of the
group, as is any agreement on a solution.

-Jonathan R.
---