Subject: [MMUSIC] comedia-fix and the whole source address/port boondoggle

From: David Yon <[email-masked]>
Date: Tue, 07 Jan 2003 09:20:00 -0500

comedia-fix again raises the argument against embedding the source 
address/port information in the SDP.  That is something that I still feel 
strongly about, and work has progressed that makes use of it, although not 
as a fail-safe session correlation mechanism.  We've found that it's useful 
as a DoS counter-measure, using the following design:

	- An intermediate proxy on our network acts as a STUN-like
	  inverse-NAT translator to at least recover the likely address
	  from where the media will originate, and rewrites the SDP
	  if necessary.

	- Our gateways, when under load, sort the incoming connection
	  pending queue based on source addresses that they expect
	  to arrive.

The idea is that when under DoS attack, connections sourced from uninvited 
addresses are not dealt with until the queue of invited addresses has been 
serviced.  This is especially critical when the media is carried over TLS, 
and in our case we do not commence with the TLS handshake until either the 
connection has been correlated or until servicing the connection does not 
overload the gateway.  The side-effect of a failed/incorrect inverse-NAT 
rewrite only occurs under heavy load, and is not fatal.  But without the 
source address information, there is no way to implement such a scheme.

I believe that comedia adequately spells out the limitations imposed by 
various topologies (i.e., NAT), and the source address/port is still worth 
keeping.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Jan 2003 21:02:36 -0500

Responses inline.

David Yon wrote:
> address/port information in the SDP.  That is something that I still 
> feel strongly about, and work has progressed that makes use of it, 
> although not as a fail-safe session correlation mechanism.  We've found 
> that it's useful as a DoS counter-measure, using the following design:
> 

It is quite a mystery to me how such a thing could possibly work in a 
causal fashion. The endpoint won't actually open any connections until 
after the offer/answer exchange has completed. The opening of the TCP 
connection is the thing which causes the NAT to assign a binding. So, 
the binding is assigned after the o/a exchange, but your proxy needs to 
know the binding before the exchange completes. So, I don't get it.

> The idea is that when under DoS attack, connections sourced from 
> uninvited addresses are not dealt with until the queue of invited 
> addresses has been serviced.  This is especially critical when the media 
> is carried over TLS, and in our case we do not commence with the TLS 
> handshake until either the connection has been correlated or until 
> servicing the connection does not overload the gateway.  The side-effect 
> of a failed/incorrect inverse-NAT rewrite only occurs under heavy load, 
> and is not fatal.  But without the source address information, there is 
> no way to implement such a scheme.

Since, practically speaking, I would expect the majority of users to 
connect to things from behind a NAT, this mechanism serves little 
purpose to prevent DOS attacks. I don't understand why you would not use 
more tried-and-true mechanisms, such as return routability, which 
validate a source IP address by sending it a cookie, and getting this 
cookie back. Such a mechanism actually works through NAT, and you can 
provide much more than just service prioritiziation based on it.

I still maintain that, given we are painfully aware of the trials and 
tribulations of distributing source IP addresses in protocols, and given 
the vast potential for misuse, and the potentially small (if not ZERO) 
deployable benefits of this mechanism, I would like to see it removed. 
It is one thing to include a mechanism that is useful in many cases, but 
might not work in some (and then documenting such) as compared to a 
mechanism that will most likely be misused, and whose real benefit is 
small or zero.

We should keep this bit separate from much of the rest of the 
comedia-fix stuff. I will comment on that separately (to a resolution I 
do think you will be happy with).

-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

---

From: David Yon <[email-masked]>
Date: Wed, 29 Jan 2003 08:39:27 -0500

At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote:
>>strongly about, and work has progressed that makes use of it, although 
>>not as a fail-safe session correlation mechanism.  We've found that it's 
>>useful as a DoS counter-measure, using the following design:
>connection is the thing which causes the NAT to assign a binding. So, the 
>binding is assigned after the o/a exchange, but your proxy needs to know 
>the binding before the exchange completes. So, I don't get it.

It works on ranking rather than absolute correlation.  You're correct about 
the NPAT port binding not being known ahead of time.  However, most NPAT 
scenarios involve a single IP Address, so a media connection coming from 
that IP Address (regardless of source port) would be ranked higher than one 
that comes an unknown address.

And let's not forget about connections that originate from dial-up accounts 
(which accounts for the vast majority of home access), where the IP Address 
and port are actually correct, in which case the ranking is 100% accurate.

>connect to things from behind a NAT, this mechanism serves little purpose 
>to prevent DOS attacks. I don't understand why you would not use more 
>tried-and-true mechanisms, such as return routability, which validate a 
>source IP address by sending it a cookie, and getting this cookie back. 
>Such a mechanism actually works through NAT, and you can provide much more 
>than just service prioritiziation based on it.

Again, the scheme as described works in the presence of NAT (despite 
assertions to the contrary), and allows the media to be 100% TLS without 
any out-of-spec "enhancements".

>deployable benefits of this mechanism, I would like to see it removed. It 
>is one thing to include a mechanism that is useful in many cases, but 

It is OPTIONAL in the spec, and the limitations clearly outlined.  At least 
one implementation finds it useful.  I don't know how to be more clear than 
that, and why it causes such heartburn.

>We should keep this bit separate from much of the rest of the comedia-fix 
>stuff. I will comment on that separately (to a resolution I do think you 
>will be happy with).
>
>-Jonathan R.
>
>--