Subject: RE: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

From: "Yutaka Takeda" <[email-masked]>
Date: Tue, 17 Feb 2004 19:24:10 -0800

> With ICE, a UAS will first check connectivity to UAC's STUN address.
> The ICE draft suggests doing so on the initial application request
> (SIP INVITE e.g.) to keep call set up time low. At this 
> moment however, 
> UAC's NAT is not primed yet and the STUN check reports no 
> connectivity.

My understanding is that the connectivity check is done at the same time
at both ends. The UAS (responder) may initiate the connectivity check
first, the UAS will send 183 Session Progress with SDP (accept message)
back to the UAC (initiator) without waiting for completion of the connectivity
check. UAC will start the connectivity check immediately after it receives the
accept message. Timeout duration of STUN transaction is 9.5 seconds
which is long enought for UAS to initiate the connectivity check before UAS
side connectivity check is complete.

BTW, 9.5 seconds seems to me too long. I would like to know if there is
a specific reason for that.

Yutaka

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Saturday, February 14, 2004 8:09 AM
> To: Jonathan Rosenberg
> Cc: Midcom
> Subject: Re: [midcom] [Fwd: I-D 
> ACTION:draft-jennings-midcom-stun-results-00.txt]
> 
> 
> At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote:
> >I disgaree.
> >
> >Cullen's results show that we are seeing hybrid NATs whose 
> type depends on whether the random port selected by the 
> client is allocated already or not. In such a case, if the 
> client picks an already-allocated port during the detection 
> phase, it may detect the nat as symmetric, when it fact it 
> might be port restricted in other cases.
> >
> >With ICE, if you happen to be unlucky during a stun 
> allocation, turn would get used. If you're lucky, and you get 
> a port-restricted port, then the relay would not be used.
> 
> So here is a case which makes me puzzled and possibly needs some
> extra work: SIP client behind a restrictive NAT. With STUN assumptions
> it will work (as long as they hold, of course),the client will send 
> a "primer" packet to UAS and UAS media will come in.
> 
> With ICE, a UAS will first check connectivity to UAC's STUN address.
> The ICE draft suggests doing so on the initial application request
> (SIP INVITE e.g.) to keep call set up time low. At this 
> moment however, 
> UAC's NAT is not primed yet and the STUN check reports no 
> connectivity.
> 
> -jiri
> 
> --
> Jiri Kuthan            http://iptel.org/~jiri/ 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 18 Feb 2004 05:36:13 +0100

At 04:24 AM 2/18/2004, Yutaka Takeda wrote:
>at both ends. 

I am not sure ICE is now suggesting UAC's connectivity checks and I still see 
race conditions potential in the call flow. For example, UAS may get ICMP errors 
for the connectivity checks before UAC receives 183 and primes its NAT with its 
connectivity checks. 

-jiri

>The UAS (responder) may initiate the connectivity check

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Feb 2004 23:53:41 -0500

Yutaka Takeda wrote:

> check.

This is allowed, yes.

> UAC will start the connectivity check immediately after it receives the
> accept message.

Right.

> Timeout duration of STUN transaction is 9.5 seconds

I think you mean "long enough for the UAC to initiate the connectivity 
check before the UAS side connectivity check is complete".

I believe that will work, yes, though it does REQUIRE the UAS to issue a 
183 immediately, as opposed to waiting as long as it wants.

In the current draft, the original approach for dealing with port 
restricted was to do another ice cycle, i.e., a second o/a exchange 
which would re-do the checks. However, doing it with a single cycle 
would be highly preferred, so I like Yutaka's suggestion on this.

> a specific reason for that.

Typical value for transaction timeouts on public Internet. SIP uses an 
even larger number, 32s. STUN is quite aggressive by comparison.

Also, note that with ICE, the clients will use the "default" media path 
- generally through a relay - until the connectivity checks yield 
something better. So you'll still get media flowing even if the checks 
take much longer.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Feb 2004 23:55:57 -0500

Jiri Kuthan wrote:

> I am not sure ICE is now suggesting UAC's connectivity checks 

Yes, ICE has both sides doing checks.

> and I still see 

My understanding is that most NATs do not generate ICMP if you hit 
unallocated ports, as it would facilitate port scans. However, if this 
is a real concern, its easily addressed by simply mandating the checks 
on the uas side get done over some duration so that you are sure they 
really have failed.

Are there other race conditions you know of?

-Jonathan R.