Subject: RE: [SIP] A warning to implementors

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2000 02:05:48 -0400

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Friday, September 15, 2000 1:06 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [SIP] A warning to implementors
> 
> 
> I agree that an arbitrary limit of 16 characters is simply 
> wrong. However,
> saying that the field length should be unbounded is not a 
> good idea, either.
> 
> Arbitrary-length fields are not really consistent with 
> Section 3 of RFC
> 2543.  This section suggests a maximum SIP message length of 
> 1500 bytes (the
> LAN MTU). 

Thats another number which is rapidly being approached (actually, I've seen
it exceeded in some complex scenarios). I would also warn people against
dropping requests that exceed this.

Such a suggestion is very important for embedded 
> applications and
> UDP applications.  I would go so far as to suggest that we 
> set a maximum
> length to a SIP header field of 1000 bytes.  This enables 
> fixed-memory,
> embedded applications to run without barfing. 1000 bytes is 
> effectively
> infinite.

Really? 1000 is much less that infinite last I checked.

I understand the issues for embedded systems. Its nice to
make assumptions about sizes so you can pre-allocate buffers
and things like that. But, these ultimately lead to interoperability
problems. The bigger the number, the less likely, and the farther into
the future the problems arise. So, how big is big enough? Thats the
question.
Definitely not 1000 for a header field. 

  If you don't like 1000 bytes, how about 4095?  The 
> point is to
> have some bound, even if it looks unreasonably big.
> 
> The only place I can find where we could realistically run in 
> to problems
> with this are the Response-Key: or Authorization: fields.

No; the problem is also with fields like Via and Record-Route; we are seeing
these fields get increasingly populated with stuff. This is because these
headers have the "stack" property and come back to you in some form or
another. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Sep 2000 09:06:49 -0400

Also, even for embedded systems, it is generally a good idea to allocate
space for these fields dynamically rather than statically. Setting aside
even 1,000 bytes for what is usually, say, 16 bytes is a waste of space.
Thus, large limits are no help whatsoever and just cause opportunities
for interoperability problems and various buffer-overflow attacks.
Indeed, a large limit is worse since it is very unlikely to be exercised
during normal tests, but very likely to be exploited by attackers. I'd
also agree that the 1,500 byte limit is not too helpful. We should
obviously try to keep messages below that, but there's not much you can
do if you need large keys. Again, speaking from experience, lulling
people into the notion that they don't have to deal with IP
fragmentation can be very dangerous since there seem to be circumstances
where a perfectly "nice" packet gets fragmented due to various
encapsulation rules, without the sender having a clue. Note that the
current MTU-related wording is SHOULD NOT, indicating that there may be
valid reasons to ignore the prohibition.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs