Disabling backward compatibility for some messages only

[GoogleCodeExporter]

What steps will reproduce the problem?
1. .Proto doesn't have option to disable  backward compatibility for a message
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Latest

Please provide any additional information below.
My keeping messages to be extended for forward compatibility provides an 
opportunity to send a message with huge optional fields causing a DoS. Suppose 
if i have an authentication message in .proto with fields username & password. 
An unauthorized user can send a invalid username & password with GBs of 
optional field which could easily fill up my server memory. It would be better 
if there is an option to disable optional fields support for some messages.

Original issue reported on code.google.com by d.vas...@gmail.com on 6 Sep 2014 at 1:22

[GoogleCodeExporter]

Why are you accepting gigabytes of data from an unauthenticated user in the 
first place? If you are allowing that, there are many other ways to consume 
resources regardless of optional field support - disabling optional fields in 
the parser gains you nothing. You should be restricting this before it gets 
near the parser in the first place.

Original comment by Oliver.J...@gmail.com on 6 Sep 2014 at 9:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

We can always use message limits to drop messages which are larger in size. Its 
better we have a explicit way to disable optional fields on some message. There 
are some messaging framework which support this functionality to avoid DoS 
attacks with optional fields. Example Microsoft WCF has support for disabling 
extensible messages by not implementing IExtensibleDataObject interface in a 
data contract.  

Original comment by d.vas...@gmail.com on 7 Sep 2014 at 4:32

[GoogleCodeExporter]

Can you explain how the DoS attack would work with a message limit of, say, 4kB?

Original comment by Oliver.J...@gmail.com on 7 Sep 2014 at 9:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

 4KB is too little, it will break forward compatibility in most cases. People prefer binary encoding like google protocol buffer as the data on wire is bigger in size. I believe that there might be some genuine cases where we need to set a high message limit say 30Mb. If a attacker sends a message  with 1kb required field & 28MB optional fields then the parser would successfully unpack the data. After that the application would keep the message in memory for further processing. If these messages get accumulated after a while the system memory fills up causing DoS. Setting a message limit actually reduces these attacks. Better option would be to avoid optional fields for some message.

Original comment by d.vas...@gmail.com on 7 Sep 2014 at 5:27

[GoogleCodeExporter]

If you require a 30MB limit for correct operation, with no optional fields, and 
you retain this data, why can't an attacker send 30MB of valid data and cause 
you problems that way?

I am really having trouble understanding exactly what you're defending against. 
Do you have an example of what a hostile message's structure would look like 
and how disabling optional fields would help?

Original comment by Oliver.J...@gmail.com on 7 Sep 2014 at 10:09