Subject: [midcom] Comments on draft-sen-sipping-intrarealm-stun-00

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 15 Sep 2002 14:15:25 -0700

This is an interesting approach to solving this problem and it got my
thinking about it. First I have a few suggestions, then a few concerns, and
final an idea for a bit of a change.

A few suggestions .....

You could easily abstract the sip part of this draft out and make it a
midcom draft by just saying that the initial address information get passed
by some protocol from A to B.

I think it would be better for the originating UA to provide a supported
connected-stun not a requires - the call will still work even if the other
side does not do connected-stun.

If A and B have discovered different IP address for their public media
address - it is very unlikely they are in the same private space. (The
previous statement might not be true - it is based on the assumption that
NAT is not really used but that PAT is).  However the converse of this is
not true - just because they are behind the same outermost NAT, does not
mean there are not other NATs along the path. For example, a cable provider
may NAT all their customers but each customer may have their own NAT at
their home.  In this example the outmost NAT for two cable customers is the
same, it is the ISPs NAT but the customers phones are in separate private
spaces because they have further NATs

My big concern .......

The idea that I could send a packet from outside the firewall to a port on
the NAT which would  send it to a stun server on the inside of the NAT and
firewall which would send it to any machine I wished inside someone's
private network is very concerning for me.

An idea ........

So let me summarize a change to this idea. I would like this to work for
many things that use STUN not just SIP. I see that that there are two things
we are trying to learn by the technique covered in this draft. The first is
"Are these two devices in the same private address space?" and the second is
"Does the outermost NAT support hairpinning?"

On the first questions - I think that at a very high level the solution
needs to look something like A passes B a token and his private address via
some previously established channel. B tries to send the token to A's
private address. If A receives it he knows how to communicate with B over
the private network. I think you have hit on a good idea that STUN, or
something like it might be a good protocol to send the token to B to A. The
part of STUN that I think makes it good for this is it's security
properties. Stop snickering, seriously I think it has about the right
security attributes.

So how about simplifying your proposal to something along the lines of A
generates a normal STUN OTP (One Time Password) puts it in the SIP signaling
along with a Supported connected-stun and sends it along. When B receives
this, B can first check if the media ports look like they might be behind
the same outermost NAT. If so it can proceed with trying to send a STUN PING
request to A. If A gets a OTP that matches - it sends a reply to B to stop
the retransmissions and knows it can communicate with B. One part I like of
this is that in the case that A is not in the same domain as A, B is
spamming only other devices on it's private network with packets that it
created. The STUN server on A would need to be defined to not be a proper
STUN server but a new type, lets call it a STUN PING server. It would always
ignore the change address and change port stuff, would also send a response
to where the request had come from, and would not need to do the TLS stuff
to hand out OTP. Because of retransmission this whole process could take
some time so the main communications (the RTP in the SIP case) need to
proceed as if they were not in the same domain then be switched to the
private domain mid call.

The second question is how to figure out if the outermost NAT supports
hairpinning. It would be really nice to do this before the phone started
ringing because if it does not, and you are not in the same private space,
you pretty much need to go to a media relay solution such as TURN. I think
this could be done around the same time that the device figures out if the
NAT is symmetric or no. The device finds it's public address, sends it's
self a packet from a different port and sees if it receives it or not.

Sorry this email is so long but I hope it is helpful,

Cullen

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