Subject: RE: [midcom] STUN over TCP?

From: "Cedric Aoun"<[email-masked]>
Date: Wed, 13 Mar 2002 22:47:34 -0000

We should be able to handle the segmentation issue without TCP, since the
message length sent by the STUN client won't normaly exceed the MTU (the
client is not sending a certificate).We already have a mechanism to
retransmit the requests if nothing happens (in case one fragment is lost).

The issue with fragmentation and NATs is when 2 NATTed clients are trying to
reach the same server and both datagrams are fragmented with the same
fragment id, the STUN server won't be able to distinguish the 2 client
messages.

I don't see this case happening here since the client is not sending several
hundred bytes certificate, am I missing something?

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 3:44 PM
To: Christian Huitema
Cc: Melinda Shore; [email-masked]
Subject: Re: [midcom] STUN over TCP?

Christian Huitema wrote:
> 
> > However, there are very serious security risks unless STUN responses
> are
> > well protected. If I could inject a fake stun response, containing my
> > own IP address and port in the MAPPED-ADDRESS attribute, I can steal
> > peoples phone calls, re-route media, and so on. All sorts of really
> bad
> > things. It would be an effective back door to break security of any
> > application protocols that would use STUN.
> >
> > Now, we debated whether or not to use a public key mechanism to sign
> the
> > responses, or shared secret. The latter would allow us to use a simple
> > keyed HMAC, much, much less complicated. However, its not practical. A
> > server does not authenticate itself to a user with a shared secret. On
> > the web, its with server certificates in TLS/SSL. The simple fact is
> > that you will want to use stun servers in domains you don't even have
> a
> > shared secret with at all.
> 
> There are several levels of protection that can be implemented, and
> result in various trade-off.
> 
> The simplest protection is to insert a "nonce" in the request, and to
> check that the "nonce" is copied in the response. This prevents attacks
> by parties that are not on the direct path between the STUN client and
> server, and is almost free from an implementation point-of-view. The
> level of protection is equivalent to the one of clear-text signaling
> protocols.

Right. We always had that, in the form of the transaction ID in the
request, which had to be mirrored in the response. 

> 
> The simpler protection can be complement by a simple test on the
> returned mapping. If the clients already obtained mappings in a secure
> way, and if the IP address component in the new mappings is the same as
> the address in a previous mapping, then the risk of just using the
> mapping provided is very limited.

True; this won't work for nats which are mapping addresses into more
than one public IP address, though.

> 
> All other protections imply having a form of digital signature, which
> makes the STUN server notably more expensive to run. The simplest
> cryptographic solution is to assume that the STUN server has a public
> key certificate, and uses the private key associated to the public key
> certificate to sign the responses.

Right. THis is what we do in stun-01.

> 
> Melinda correctly points out that certificates can be very large. We
> should not require that the full certificate be transmitted in every
> response. A better design would be to carry a signature in the response,
> and to also provide the URL at which the response can be obtained.

We do something slightly different, which is to carry only the signature
in the UDP response. But, if you send the request via TCP, you get the
certificates too. All of the other data from the TCP response is not
useful - just the certificates are useful. One you have them, you can
store them, and you won't need to retrieve them again from the same
server (until they expire).

> 
> Using any form of cryptography closes one type of attack (forged
> responses) but creates another, the possibility to bring the server down
> by forcing it to sign a large number of queries. It also open a
> distributed denial of service avenue, as responses can be much longer
> than queries. Both risks can be mitigated by using a four ways
> handshake:
> 
>         Request mapping + nonce A -->
>                 <-- mapping + nonce A + nonce B
>         Request signed mapping + nonce B -->
>                 <-- signed mapping
> 
> The idea being to force the client to send back a cookie to the server,
> proving that the initial message did not come from a forged address,
> before sending a signed mapping. Note that the algorithm also enables
> the client to decide whether or not to request the signed mapping.

Right. We also have this in stun-01 using the cookie. The flow looks
exactly like what you have above, with nonce A = transaction ID, and
nonce B being the cookie attribute.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Mar 2002 03:07:12 -0500

Cedric Aoun wrote:
> 
> We should be able to handle the segmentation issue without TCP, since
> the message length sent by the STUN client won't normaly exceed the MTU
> (the client is not sending a certificate).

THe problem is in the response. The response needs to have certificates.

> We already have a mechanism to

Its not just loss probabilities, its the total failure of fragment
traversal through NAT.

> 
> The issue with fragmentation and NATs is when 2 NATTed clients are
> trying to reach the same server and both datagrams are fragmented with
> the same fragment id, the STUN server won't be able to distinguish the 2
> client messages.

No; the problem as I understand it is that most nats won't refragment an
IP packet. So, they totally ignore fragment bits. So, the first fragment
will pass since it has the UDP header. But, the second one doesn't, and
will be dropped by the NAT since it doesn't match any UDP sessions in
progress through the NAT. Thats because the NAT thinks that there should
be a UDP or TCP header after IP, but there won't be anything.

-Jonathan R.

---

From: Mahadev <[email-masked]>
Date: Fri, 15 Mar 2002 02:19:20 -0800

> be a UDP or TCP header after IP, but there won't be anything.

This is not a big problem as such. There are NAT implementations which
take care of fragmentation issue by storing state information from the
first fragment. But then, this would work only if fragment 0 arrives
first.

-Mahadev

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Mar 2002 10:23:02 -0500

At 02:19 AM 3/15/02 -0800, Mahadev wrote:
>first fragment. 

Is this commonly the case, or is it only done on high-end devices?

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Fri, 15 Mar 2002 12:20:36 -0500

It certainly requires more complexity/expense in the NAT device.  Therefore
I think it would be safe to assume there are and will continue to be NATs
out there that do not do this.

-Mark

---

From: Mahadev <[email-masked]>
Date: Fri, 15 Mar 2002 11:02:42 -0800

Yes, this very common irrespective of the device type (low/high end)...

-Mahadev

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Mar 2002 15:18:35 -0500

> Yes, this very common irrespective of the device type (low/high end)...

Sorry - "this" meaning "support for fragmentation" or "no support for
fragmentation". I'd love to see some documented tests on residential
devices to see fragmentation support. I'd bet its not good...

-Jonathan R.

---

From: Mahadev Somasundaram <[email-masked]>
Date: Mon, 18 Mar 2002 08:04:25 -0800

>fragmentation". I'd love to see some documented tests on residential

meant "support for fragmentation".