Subject: RE: [midcom] pre-midcom work item

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 11:29:54 -0400

> -----Original Message-----
> From: Ram Dantu [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 9:44 AM
> To: Jonathan Rosenberg; Abdallah Rayhan; Melinda Shore; 
> [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> Jonathan,
> 
> Following are my observations on the
> draft. I appreciate if you can confirm/clarify my observations:
> 
>   - How to handle traversal through multiple NATs is not
>     clear in this draft. For example, if the VOIP 
>     call goes through more than one service provider, 
>     (Section 5, paragraph 4)are the STUN servers 
>     going to talk to each other?

No, no, definitely not.

> How are we handling this case?\

In the stun model, each user has a service provider. The client talks to the
stun server of their service provider. Through that communications, they
obtain a publically usable IP address for media. That requires no
coordination between providers.

So, consider the case where I am a user of foo.com (sip:[email-masked]).
When I start my phone, my phone uses stun, and talks to the foo.com stun
server on the public Internet. Using the discovery procedure in the spec, my
phone discovers that there is at least one nat between me and the public
Internet, and that its full cone.

Now, when I make a call to sip:[email-masked], I send a stun query to the
server, and get back my IP address. I then use that in the SDP in my INVITE.
From here, its regular, plain old vanilla sip. I send an INVITE to my proxy
at foo.com, and it looks up bar.edu in dns, and forwards the INVITE there.
That goes to alice. Alice may be behind a nat - but thats her problem. She
would use the stun protocol as well to learn her public ip address, and she
would use the bar.edu stun server to do that. Once she gets one, she sends
back a 200 OK with that address in the SDP, and we're all set.

The detailed usage of stun for sip will be described in a to-be-written I-D
for the sipping group.

> 
>  - For every call the NAT bindings have to be discovered. 
>    (Section 9.3). This imposes serious limitation to this approach.
>    For example, the latency and scalability issues ?

The usage of stun will add one RTT of latency between a client and the stun
server, if one side is behind a nat. If both sides are behind a nat, its
two. I don't consider this a serious increase in latency, especially
considering the alternative - no media.

As for scalability, this scales really well. Stun servers are stateless. You
can have farms of them using SRV lookups. What about it doesn't scale?
 
>  
>   - Determining the timeout discovery (Section 9.2)
>     is trial and error method and very time consuming 
>     process and poses scalability and latency problems.

Yeah, it would take a while. Its one of these things you would do in the
background when the phone comes on. I don't see the scalability issue
though.

> 
>   - If we run the STUN client in Server, how are we going
>     to pass on the NAT binding to media component 
>     (e.g., Section 9.3, paragraph 4)

Again, this is something that will be described in far more detail in the
sipping draft. The idea here is that within an enterprise, you could have a
"B2BUA with media". THis would be a server on the inside of the nat, which
receives the INVITE requests from clients within the enterprise. This server
would be the one to act as a stun client, and it would rewrite the SDP based
on the addresses it receives. It would, as a consequence, be on the media
path, so that media from the outside goes to it first, and then to the
clients. The advantage of this approach is that it requires no changes in
client software, only the addition of this element on the inside of the
network. The disadvantage is that it introduces an intermediate point for
media relaying. 

> 
>   - Security is a big concern. From Section 11. 
>     it is clear that the both the STUN client and STUN 
>     server are prone to DOS attacks. It seems to me
>     the problem in inherent in the solution.

Oh? How is that? The stun server is stateless. How can you launch a DoS
attack against it? You can flood it with packets, sure, but thats possible
for any protocol. I do point out that the stun server can be used for
certain DDos attacks against other elements, as its a "reflector". I will,
however, note that there are other protocols that send a packet when they
receive a packet, which include DNS, SIP, HTTP, and so on. The remedy for
this attack is to include the source address of the attacker for tracing
purposes, which is what does happen. So, the protocol seems to
satisfactorily handle that case. 

I also don't see how the stun client is prone to attacks. Can you please
provide supporting evidence for your claims.

>    
>   - In Section 11, last paragraph, it is mentioned that if STUN
>     client is within enterprise, the server returns false
>     address. It is not clear to me how this works.
>     Appreciate more text here.

No, no. I am not proposing that a server return false addresses. All I am
saying is that a compromise of the stun server cannot introduce new holes
into the security perimeter of the enterprise. A stun server does only one
thing - returns IP addresses. The worst thing it can do is return the wrong
ones, in which case calls don't get set up. 

>  
>   - Overall, the solution depends on the discovery by the 
>     STUN agent which can be located in the user agent. 

No. First off, I don't know what a "stun agent" is, as this term is never
used in the document. A stun client exists within the user agent, but its
not discovered. Its part of the software within the client application.
I.e., my PC phone would have some code in it to implement a stun client in
order to get IP addresses.

>It appears that there a serious security problem with this solution.

Unsubstantiated claims like this serve no one. Please provide specific
objections.

> 
>   - Referring the work in progress documents [1,6] is irritating 
>     since the reader cannot get to the documents. 
>

I am sorry this irritates you. However, these documents are all readily
accessible from the IETF site. It is standard practice for an Internet Draft
to reference other Internet Drafts. "Work in progress" is the standard
terminology required when one references an Internet draft. To save you some
trouble, I took a few seconds to get the URLs for you:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-06.txt

-Jonathan R.

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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 02 Oct 2001 13:27:25 -0500

I'm jumping in in the middle of this but here goes, my questions are inline

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Tuesday, October 02, 2001 10:30 AM
> To: 'Ram Dantu'; Abdallah Rayhan; Melinda Shore; [email-masked]

They obtain an IP address, but what about a port number? does the client
guess what port number that the nat may assign to the transaction? In the
case of NAPT(PAT) there is a pool of ports being used randomly in most
cases.

Now in the case of multiple nats this gets even more complicated, unless we
assumethe outermost nat is the ip address seed.

> Internet, and that its full cone.

What is "full cone"?  These are my only two questions for now, until I read
the rest of the draft.

-Jonathan R.

---