Subject: RE: [midcom] Moving SPAN along

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 29 Aug 2002 10:16:12 -0500

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]] 
> 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
> > 
> 
> 
> -- 
> 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]
> https://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 29 Aug 2002 17:10:21 +0100

RE: [midcom] Moving SPAN alongSanjoy,

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 :-).

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.  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 !!!

Pete.
  ----- Original Message ----- 
  From: Sanjoy Sen 
  To: 'Jonathan Rosenberg' ; Melinda Shore 
  Cc: Pete Cordell ; [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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Aug 2002 18:28:58 -0400

Sanjoy Sen wrote:
> 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.

The problem is not the case when two clients are behind the same NAT. 
There are many ways to detect this, and once you know it, you can use 
your private addresses.

The problem is when you have two clients behind two different NATs, but 
which share a common "root" NAT on the public Internet. An example is 
when users A and B both use a cable provider that NATs using a single 
NAT. Both A and B also have a residential NAT in their house. There is a 
STUn server in the public network. A and B both allocate public 
addresses from that server. The NAT in the cable network doesn't do 
loopback, so A can't send to B's public address, and vice a versa. But, 
A also can't contact B at B's private address, since they are not in the 
same address realms.

If you can detect this case (which you can), the only resolution I can 
think of is to resort to a TURN/SPAN server on the public network.

-Jonathan R.