Subject: [midcom] some comments on stun 01

From: "Cedric Aoun"<[email-masked]>
Date: Sun, 17 Mar 2002 18:52:50 -0000

Hi,
I have some comments on stun-01

Page 7,
"STUN servers are discovered through DNS SRV records [2], and is generally
 assumed that the client is configured with the domain to use to find
   the STUN server. "
I prefer saying STUN servers could/might be discovered, I think we should
clearly decouple STUN 
from the ability to send DNS SRV record queries to find the STUN server.

Section 9.2 page 17 
"It then starts a timer with a
   value of T seconds. When this timer fires, the client sends a request
   to server A, with the "change IP" and "change port" flags set. If the
   binding is still active, this response should be received through all
   nat types."

This bind expiry timer discovery method works only for NATs that are not
full cone NAT. When the NAT is full cone, 
it won't work since we have refreshed the bind by sending out the message to
the original server I suggest adding a 
timer in the STUN query when the NAT is found full cone. This counter will
be used to say after how many secs
 the server should reply back.

Section 12, page 23; Cullen mentioned this issue already where a specific
protocol name will need to be assigned 
when used in DNS SRV records, Jonathan provided already the name.The next
version of the draft will need to incoeporate the "nat-stun-port"

page 24, section 13.2
"STUN can also help facilitate the introduction of midcom. As midcom-
   capable NATs are deployed, applications will, instead of using STUN
   (which also resides at the application layer), first allocate an
   address binding using midcom. However, it is a well-known limitation
   of midcom that it only works when the agent knows the middleboxes
   through which its traffic will flow. Once bindings have been
   allocated from those middleboxes, a STUN detection procedure can
   validate that there are no additional middleboxes on the path from
   the public Internet to the client. If this is the case, the
   application can continue operation using the address bindings
   allocated from midcom. If it is not the case, STUN provides a
   mechanism for self-address fixing through the remaining midcom-
   unaware middlboxes. Thus, STUN provides a way to help transition to
   full midcom-aware networks."

This is only valid only if a peer to peer STUN messaging is launched to
discover if there are no 
other NATs traversed by the Media flow, this is actually one of the issues
of STUN, in case a realm 
has several NATs on its boundaries the STUN stream (between the client and
the STUN server) 
could be sent to a different NAT than the media stream. 
I think that we should have this stated in a STUN applicability statement.

page 27, section 13.6
"The result of this lack of standardization has been a
   proliferation of devices whose behavior is highly predictable,
   extremely variable, and uncontrollable"
Did you originally mean highly unpredictable?

Cedric

Cedric Aoun 
Nortel Networks 
France 
<mailto:[email-masked]>