Re: [reSIProcate] Hardening the parser (what goes into 1.0?)
On 8/7/06 10:14 AM, "Byron Campen" <bcampen@xxxxxxxxxxxx> wrote:
Given that the maximum size of a SipMessage is 64K, I think it is safe to assume that a UInt32 will be enough.
Where did that assertion come from? We’ve successfully passed 700MB MESSAGE requests through a reSIProcate based product before. Don’t confuse the MTU for a particular transport with the ‘maximum message size’. :-) One thing that is worth considering; adding explicit support for a maximum message size (settable by the stack user). There are advantages to having a practical max.
Secondly, there were some items you raised that I disagree with; Content-Length is important, however when it is in disagreement with the transport framing, I think we should believe the transport. (SCTP/UDP/DTLS) in cases where we NEED the CL, then we should pay close attention to it (and we do). Again, this is where the concept of a maximum sounds reasonable. The parser should consider returning reasonable results if the CL field is larger than UINT32_MAX. (What would make sense? If the transport needs framing, what would we do? The connection would need to read UINT32_MAX+k bytes and we would have no mechanism to remember k.)
Should we just close the connection when the CL is larger than our max message size? Think about that...
A
I guess I mis-remembered that detail. But, does UInt32 sound like a reasonable limit? Or should we go with UInt64 so file transfers of larger than 4G can be carried out using a single sip request? Is any other implementation on the face of the planet likely to accept a Content-Length this large?
As for whether Content-Length should be believed, I think we should at least make this behavior configurable.
Best regards, Byron Campen
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature