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

From: "Ram Dantu" <[email-masked]>
Date: Tue, 2 Oct 2001 08:43:45 -0500

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? How are we handling this case?

 - 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 ?
 
  - Determining the timeout discovery (Section 9.2)
    is trial and error method and very time consuming 
    process and poses scalability and latency problems.

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

  - 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.
   
  - 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.
 
  - Overall, the solution depends on the discovery by the 
    STUN agent which can be located in the user agent. It 
    appears that there a serious security problem with this solution.

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

Regards
Ram Dantu Ph.D.,
Netrake Corporation
3000 Technology Drive #100,
Plano, Texas, 75074
[email-masked]

DISCLAIMER: The opinions expressed in this email are
my own and do not represent my employer

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, October 01, 2001 4:40 PM
To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore;
[email-masked]
Subject: RE: [midcom] pre-midcom work item

Folks,

I've just submitted an I-D to the archives, co-authored with Christian
Huitema and Rohan Mahy, on what this protocol might look like. Until it
appears in the archives, you can pick it up from:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt

Its just a step above "echo", but it can determine the presence of nats,
diagnose the type, and help determine binding lifetimes. This protocol
will
suffice to help a SIP enabled voip phone get through a fairly large
fraction
of nats (full cone and restricted cone, which is about 80-90% of nats
depending on who you ask) while still maintaining direct, end-to-end
voice
transport. The protocol is totally independent of sip; a separate draft
(in
sipping) is pending on how to use the stun protocol in a sip client. 

Comments/questions/flames welcome as always. Hopefully this will help
clarify the kind of things the new charter item is aiming at.

Thanks,
Jonathan R.

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 2:21 PM
> To: Jonathan Rosenberg; Melinda Shore; [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> --- Jonathan Rosenberg <[email-masked]> wrote:
> 
> > > Secondly, this introduces
> > > new architectural constraints that is going to screw
> > > the consensus achieved so far on the architecture draft.
> > 
> > How is that?
> 
> Before amending the charter we at least need to know
> what and how this would work. Instead we got a charter
> change dictated on us before learning how this 
> SIP-happy-NAT is going to influence the current architecture,
> or being discussed and scrutinized by the WG.
> 
> <snip>
> > > 
> > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop 
> > > the WGs from developing those standards. Why should we be
> > > the exception?
> > 
> > No one is saying that it should not be deployed. Full steam 
> ahead. We
> > need
> > midcom, and that hasn't changed. The fact is that midcom can't fully
> > solve
> > our problems.
> > 
> > Its also worth noting that there are already solutions 
> being deployed
> > today
> > that play the role of the proposed addition. Those are all
> > proprietary and
> > not interoperable. Let us not let that continue.
> 
> What will happen is another beast will be added to the gang.
> 
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
> 

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

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

---

From: Li Li <[email-masked]>
Date: Thu, 4 Oct 2001 15:09:02 -0400

A few quick questions about the stun draft:

(1) in section 9.1, close to the bottom of p.10,

"If a response is received, the client knows that it has open access to the
Internet (or, at least, its behind a firewall that behaves like a
port restricted NAT, but without the translation)."

Why it is like a port restricted NAT? To me somehow this behaves more like
a full cone NAT without translation?

(2) I can see STU works well with the full-cone nat. But how about 
restricted cone or restricted port? It may help if these two cases can
be explained in the draft. I remember saw in previous emails that the
restricted
cone and port restricted cone nats are all supported? The public IP
address/port 
learned from the server can only be used by the server, not the other party
in the 
call that wants to send you audio? How can the client get the mapped address

that can be used by the sender? 

(3) The changed address is returned to the client. How client uses it?  

Thanks in advance,

Li Li

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 01:43:03 -0400

> From: Christopher A. Martin [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2001 5:16 PM
> To: 'Jonathan Rosenberg'; '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.
> >
> > My apologies for being imprecise. Yes, they obtain the port
> > number too. The
> > server returns an attribute called MAPPED-ADDRESS which
> > includes a port and
> > IP address. Our assumption was that NAPT was the norm.
> 
> Excellent. Does the attribute also facilitate the RTCP port as well?

You would need to use a separate socket, and thus obtain a separate
MAPPED-ADDRESS, for RTCP. This has the unfortunate side effect that the RTP
and RTCP ports will no longer be adjacent. However, at the last avt meeting
it was agreed that this was OK so long as the signaling indicated that RTCP
was a different port. There is now an mmmusic work item to define an SDP
extension for RTCP IP addresses and ports, draft-ietf-mmusic-sdp4nat.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 02:09:02 -0400

-----Original Message-----
From: Li Li [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 3:09 PM
To: 'Jonathan Rosenberg'; [email-masked]'; [email-masked]
Subject: RE: [midcom] pre-midcom work item

>a full cone NAT without translation? 

Yes, you're right. This is an error.

restricted 
address/port 
in the 
>that can be used by the sender? 

We were trying to focus on just the protocol, and not its usage for SIP, so
many of these details, which are very important, were not in here.

In the case of restricted cone nats, it will work just fine if the peer
sends and receives from the same IP address. This is not always true (i'll
explain in a moment how to handle that case when its not). Assuming it is,
lets say its A (behind a port restricted NAT) calling B. A uses stun, and
gets an address. It puts that into the INVITE SDP. The 200 OK comes back.
That contains the address that B will receive on. A takes that address, and
"primes" its nat by sending a packet to that address. The nat will now allow
packets to A from that address. Since I assumed that the address that B
receives on is also the one it sends from, packets from B will flow through
the nat to A.

Now, it won't always be true that B sends from the same IP it receives on.
The way to handle that is symmetric RTP. Symmetric RTP is nothing more than
RTP where one side sends packets back to the source address/port where it
got packets from. Handling this in SDP is documented in
draft-ietf-mmusic-comedia, which describes generally connection oriented
media in SDP. By definition, this meets the constraints in most cases. 

Port restricted are more complicated (as is symmetric nat), and it requires
a common media intermediary on the public Internet. Thats not addressed in
stun, although we debated putting it in (security was a bit more complex).

>(3) The changed address is returned to the client. How client uses it?  

Its used in the tests for full cone.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Oct 2001 09:24:45 -0400

> Sent: Tuesday, October 09, 2001 2:30 PM
> To: 'Jonathan Rosenberg'; [email-masked]
> > > I can see the idea of including the internal address in an
> > > external packet
> > > (in the clear) as being considered as a possible security
> > > risk by the IT
> > > community. This approach should be considered very carefully,
> > > since VoIP and
> > > gaming are two completely different animals.
> >
> > If you are concerned about revealing internal IP addresses
> > outside, then
> > that would be an issue independent if you were using games or
> > VoIP, right?
> 
> That is correct..was just using those as an example.. the 
> issue of divulging
> internal addressing is actually an item that is frowned upon by many
> security policies. As such we should consider this. Should I 
> take this to
> the SIP mailing list to discuss this since we are talking in 
> terms of a SIP
> working item arent we?

Its an mmusic thing, actually. Now is a good time, since a related thread
has just started - on including both v6 and v4 addresses in SDP as alternate
addresses for the same media stream. Same problem here.

-Jonathan R.

---