[reSIProcate] Content-Length is not taken seriously by SipMessage

[Byron Campen]

> On 8/3/06, Byron Campen <bcampen at estacado.net> wrote:
>>         When a SipMessage is created, the value in the Content- 
>> Length header
>> is ignored. Instead, we assume everything that remains in the buffer
>> is part of the body, and use that to calculate our Content-Length.
>> Technically, we must take the Content-Length header-field-value
>> seriously, and ignore/discard any extra bytes. Why aren't we doing  
>> this?
>>
>
> I assume you are talking specifically about the UDP transport. In the
> case of TCP/TLS the content-Length header is required to do framing.
> For UDP, since the message comes over a UDP datagram, we know it came
> from the sender. There is a DOS attack possible here where you could
> send a 64k datagram but the same attack is possible if you send a 64k
> datagram with a 64k Content-Length. A solution to this is to simply
> limit the maximum size of UDP packet that can be received, scanned and
> parsed.

This is all fine and good, but what if we are going to be forwarding  
something that might have garbage tacked to the end of the body? RFC  
3261 section 18.3 is very specific about this; we MUST take Content- 
Length seriously, even over UDP.

Best regards,
Byron Campen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060803/488348d6/attachment.bin>