Subject: [midcom] Re: some comments on stun 01

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Apr 2002 00:00:16 -0500

Cedric Aoun wrote:
> 
> Hi,
> I have some comments on stun-01

Thanks for your comments. Responses inline.

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

OK. I'll change to "can be discovered".

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

Excellent point.

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

I'd rather not do that, since it introduces state into the servers. 

How about this:

1. the client sends a request to the server, from socket X. It is sent
to address/port C,D. The response is sent from C,D. From the response,
the client learns the public IP/port for this request, say thats A,B. 

2. after T seconds, the client sends a second request, from a different
socket (Y), to the server at C,D. This one has a RESPONSE-ADDRESS of
A,B. The server sends a response from C,D to A,B. If the old binding
still exists, it is matched for all nat types, and the response goes to
socket X. If the binding had timed out, the response will either be
discarded, or it is possible that it might get sent to socket Y. In
either case, the client knows that the binding has expired.

I believe that will work.

> 
> 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"

Actually, no. The port has been registered and obtained outside of the
spec. No IANA considerations section is needed to obtain it. I can
merely include the actual port number in the document.

> 
> 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,

Right.

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

This particular validation scenario would require the stun server to be
embedded within the end system, so that this would not happen.

> I think that we should have this stated in a STUN applicability
> statement.

I've added an applicability statement, in fact, giving some of the
caveats up front. However, it doesn't talk about this e2e usage. The
usage e2e is mentioned as a possibility in a few places now. I think
that sufficient.

> 
> 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?

Yes, thanks.

Thanks for your comments!

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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