Subject: Re: [SIP] A warning to implementors

From: [email-masked]
Date: Mon, 18 Sep 2000 19:12:30 +0530

I tend to agree.
Preferring static over dynamic memory for a SIP stack for embedded systems
does not necessarily mean that its acheived
by statically allocing Xk for every header, whether it needs it or
not.Similar results can be acheived if your stack can
work with a customised backend memory manager which can preallocate some
fixed block to be used by any entity
and then give 'dynamic' chunks from it to requesting sip entities. This way
the OS still does not suffer from fragmentation.

Basically, the point is, posing such limits to a SIP message really does
not help that much, imho. As was rightly pointed out,
often a message size can exceed not because a particular header is 1000
bytes, but because the message happened
to traverse a series of proxies which all inserted normal size Via & Route
headers. Often people designing sofware for
'embedded SIP' like phone et. al assume that since they are scaled down,
they can handle 1500 byte messages and that is
good enough -  as pointed out, even such a simple device can be at the end
of a long list of proxy chains.

If you need to specify max size, I personally would prefer a max. size for
a complete SIP message (for n/w read buffer
maybe) as compared to limits for particular headers. (ie I'd much rather
say that he complete message can be of max
size 4000 bytes rather than saying From can be of 200, Route of 300
etc......)

However,
I do agree that in many systems, an implementor might want to specify
maximum SIP message size - especially in systems where
size of a text buffer does not grow dynamically (ie the convenience of s =
s + newheader resulting in s being automatically
increased is not there. In such environments, especially when a parsed
message is re-encoded into a textual buffer, it
may make sense to specify a fixed size for the output buffer, rather than
goin thru the overhead of doing limit checks
everytime and realloc() thereof- but that is really an implementation
issue. A good stack should let the user decide how
paranoid he wants to be with space allocation (ie static or dynamic) )

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Henning Schulzrinne <[email-masked]> on 09/18/2000 06:36:49 PM

To:   Jonathan Rosenberg <[email-masked]>
cc:   "'Eric Burger'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>

Subject:  Re: [SIP] A warning to implementors

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

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

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

---

From: [email-masked]
Date: Mon, 18 Sep 2000 08:57:39 -0500

> -----Original Message-----
> From: EXT [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 9:43 AM
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; 'Eric Burger'; [email-masked]'
 . . .
> size 4000 bytes rather than saying From can be of 200, Route of 300

Note that the example of content-length in rfc-bis is "Content-Length:
3495".

---

From: [email-masked]
Date: Tue, 19 Sep 2000 09:05:48 +0530

Actually 4000 is just representational. I dont mean *I* use 4000 :-). How
much of len you want to alloc is again
a very implementation specific issue.
Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

cliff> Note that the example of content-length in rfc-bis is
"Content-Length:
cliff> 3495".

[email-masked] on 09/18/2000 07:27:39 PM

To:   archow
cc:   [email-masked]

Subject:  RE: [SIP] A warning to implementors

 . . .