Subject: RE: [midcom] Moving SPAN along

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 29 Aug 2002 11:54:53 -0500

Pete, Thanks for your comments. Comments inline.

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]] 
Sent: Thursday, August 29, 2002 11:10 AM
To: Sen, Sanjoy [NGC:B677:EXCH]; 'Jonathan Rosenberg'; Melinda Shore
Cc: [email-masked]
Subject: Re: [midcom] Moving SPAN along

Sanjoy,
 
I think as you've described it, the Bind Request from A won't (normally) get
to B because the path relies on the NAT supporting loopback.  You need
something external to the NAT to bounce the STUN Bind Request off of which
sends it to B.  Either additional features could be added to STUN or you
could try source routing :-).
[SS] Didn't want to change the protocol, if not required. 
 
If you could guarantee that B was running a STUN server, you might be able
to use the fact that you didn't get a response back to either request to
imply that you were behind the same NAT.  
   
[SS] That's exactly correct. We've banked on the retransmission mechanism in
STUN to ensure a reponse if there's a path through the NAT.
 
 That seems to involve a lot of assumptions though.
 
There might be some other permutation that works.  One worry though is that
A's request may actually result in B sending packets to C.  Depending on the
context of C this may ring some alarm bells.  Maybe that's not so important
- still thinking !!! 
[SS] Yes, this can happen if C there're overlapping private addresses
between A's and B's realms. C will get an unsolicitated STUN response. But I
don't think there's any security risk here.  

Pete.

----- Original Message ----- 
From: Sanjoy Sen <mailto:[email-masked]>  
To: 'Jonathan Rosenberg' <mailto:[email-masked]>  ; Melinda Shore
<mailto:[email-masked]>  
Cc: Pete Cordell <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  
Sent: 29 August 2002 16:16
Subject: RE: [midcom] Moving SPAN along

We should be able to solve the problem by using STUN in a peer-to-peer
fashion between the endpoints. Suppose client A and B are behind the same
NAT. Client A (or B) will send two STUN BIND requests to the public address
of B - in one of the STUN BIND requests, the Response-Address field is set
to the private address of A. If the two users are behind the same NAT (share
the same private realm), then A will receive a response to the BIND request
carrying the Response-Address, and may or may not get a response to the
other request based on whether the NAT supports loopback or not. 

Then the IP address can be updated by sending a reINVITE or UPDATE as
required. 

Thoughts? If the idea seems acceptable, we can write up a short ID and
submit. 

Sanjoy 

> -----Original Message----- 
> From: Jonathan Rosenberg [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, August 28, 2002 8:41 PM 
> To: Melinda Shore 
> Cc: Pete Cordell; [email-masked] 
> Subject: Re: [midcom] Moving SPAN along 
> 
> 
> I think the problem is important. Note that, you need 
> something in the 
> TURN/SPAN area even for full cone NAT. There are cases where 
> two users 
> are behind a full cone NAT, but the SAME full cone NAT. STUN, in this 
> environment, would require the NAT to receive a packet on the inside, 
> addressed to a public IP corresponding to another one of its 
> bindings. 
> Most NATs apparently do not properly turn the packet around to the 
> private address for the second binding. This case can be 
> detected with 
> STUN, but it cannot be fixed with STUN. 
> 
> -Jonathan R. 
> 
> Melinda Shore wrote: 
> > At this point there seems to be very little support for 
> continuing to 
> > work on SPAN.  The question is whether or not the problem of 
> > traversing symmetric NATs is sufficiently compelling.  If it is we 
> > need to continue; if not we can consider dropping the deliverable.  
> > Let's try to resolve this question over the next few days. 
> > 
> > Melinda 
> > _______________________________________________ 
> > midcom mailing list 
> > [email-masked] 
> > https://www1.ietf.org/mailman/listinfo/midcom
<https://www1.ietf.org/mailman/listinfo/midcom>  
> > 
> 
> 
> -- 
> 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 <http://www.jdrosen.net>
PHONE: (973) 952-5000 
> http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
> 
> _______________________________________________ 
> midcom mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/midcom
<https://www1.ietf.org/mailman/listinfo/midcom>