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

From: "Christian Huitema" <[email-masked]>
Date: Thu, 4 Oct 2001 11:12:14 -0700

There are no good solutions to this problem. The current alternative to
STUN is to have a media relay outside the NAT; the traffic between two
local hosts crosses the relay twice.

> -----Original Message-----
> From: Mark Pietras [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2001 8:20 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> Jonathan,
> 
> More of a question about the _solution_ than the particulars of STUN:
> 
> Have you found a solution to the problem of "misguided" 
> media?  That is,
> when two clients are behind the same NAT and there's no 
> call-control/routing
> element with them in that same "realm?!", both will be forced 
> to assume that
> the other is on the "outside" the NAT.  Both the signaling 
> and the media
> will be sent "outside" just to be routed right back.  
> Signaling might not be
> a big deal, but media might be (from a latency or more interestingly a
> NAT-loading perspective).
> 
> Mark P.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Monday, October 01, 2001 4:40 PM
> To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore;
> [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> 
> Folks,
> 
> I've just submitted an I-D to the archives, co-authored with Christian
> Huitema and Rohan Mahy, on what this protocol might look 
> like. Until it
> appears in the archives, you can pick it up from:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt
> 
> Its just a step above "echo", but it can determine the 
> presence of nats,
> diagnose the type, and help determine binding lifetimes. This 
> protocol will
> suffice to help a SIP enabled voip phone get through a fairly 
> large fraction
> of nats (full cone and restricted cone, which is about 80-90% of nats
> depending on who you ask) while still maintaining direct, 
> end-to-end voice
> transport. The protocol is totally independent of sip; a 
> separate draft (in
> sipping) is pending on how to use the stun protocol in a sip client.
> 
> Comments/questions/flames welcome as always. Hopefully this will help
> clarify the kind of things the new charter item is aiming at.
> 
> Thanks,
> Jonathan R.
> 
> 
> > -----Original Message-----
> > From: Abdallah Rayhan [mailto:[email-masked]]
> > Sent: Monday, September 24, 2001 2:21 PM
> > To: Jonathan Rosenberg; Melinda Shore; [email-masked]
> > Subject: RE: [midcom] pre-midcom work item
> >
> >
> > --- Jonathan Rosenberg <[email-masked]> wrote:
> >
> > > > Secondly, this introduces
> > > > new architectural constraints that is going to screw
> > > > the consensus achieved so far on the architecture draft.
> > >
> > > How is that?
> >
> > Before amending the charter we at least need to know
> > what and how this would work. Instead we got a charter
> > change dictated on us before learning how this
> > SIP-happy-NAT is going to influence the current architecture,
> > or being discussed and scrutinized by the WG.
> >
> > <snip>
> > > >
> > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop
> > > > the WGs from developing those standards. Why should we be
> > > > the exception?
> > >
> > > 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.
> >
> > What will happen is another beast will be added to the gang.
> >
> > _______________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.ca address at http://mail.yahoo.ca
> >
> 
> ---
> 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
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> _______________________________________________
> 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: Scott Brim <[email-masked]>
Date: Thu, 4 Oct 2001 15:51:29 -0400

> local hosts crosses the relay twice.

...which should cause some concern for security.