4 ms·

These issues seem to be focused on the phone-side of things. Robust and high capacity servers and load balancers have other use-cases. Unless I misunderstand, a

These issues seem to be focused on the phone-side of things. Robust and high capacity servers and load balancers have other use-cases. Unless I misunderstand, all of these Date format, the header parsing, the commends in headers, querystring headers come straight from HTTP itself. Can't blame SIP for it. Unless you want to commit fully to TCP, then the fragmentation must be taken care of in the protocol, no way around it. Yes most networks are fine, but the protocol has to deal with the worst-case scenarios. UDP has a lot of advantages - two most used - the retransmissions are faster and it's stateless. It allows to have a fully stateless SIP server devices, reduced chance of DoS attacks or session/fd leaks. UDP allows you to play with the queue design on the server side since you can drop messages and wait for the faster retransmissions. UDP block parsers vs TCP stream parsers have advantages in certain cases to optimize for memory on high traffic devices. UDP allows for multicast and broadcast SIP functions. There are many other little things that make UDP easier and cheaper to deal with on the server side. The routing stuff, some of it comes from HTTP again, and then they added a bunch of extra stuff to accomodate some use-cases in federated environments and chain-systems. The source routing feature is not a problem like in IP because each server is allowed to challenge any request at any time. I've used source routing to establish sticky sessions in a cluster so I don't force replication everywhere for the same user and to create test calls that exercise specific paths in a multinode system.

MichaelGG 12y ago
The scenarios I worked on were for load balancers, proxies, and analyzers. All very high performance (at peak, 5TB/day of SIP on a single quad core processor). SIP parsing is terrible for this and leads to ugly hacky code. Same as HTTP (look at nginx's parsing code - all sorts of crazy compares). This is also why the HTTP replacement protocols ditched this nonsense. Yes, a lot of stuff came from HTTP, which likewise has no excuse other than copying previous mistakes (the date example being a prime example). Except, SIP isn't HTTP compatible, and no implementation is going to be sharing code. It'd beyond bizarre wishful thinking that an implementation is going to share any nontrivial amount of code. One of the folks from the RFC explained they aimed to make it HTTP compatible to use HTTP proxies, than gave up part way through but didn't fix up the rest of it. At any rate, you can blame SIP for it - no need to copy previous mistakes. And HTTP deserves a ton of blame, and I'd be absolutely surprised to find out that most software follows the HTTP spec. Most likely, they follow something sort of looking like HTTP, and test on the Internet to see which subset is actually being followed. Just like no one puts comments into email URIs because it's stupid. Fragmentation does _not_ need to be taken care of in protocol. IP already does fragmentation and it works. As I noted: 1-2% of all our customers had MTUs of ~576 bytes, so their SIP UDP packets were already IP fragemented. No one experienced problems with this, and some broken IP fragmentation issue would also affect TCP. UDP has a limit, but they could specify a switch to TCP at 64K. Could you clarify what you mean? UDP actually makes DoS harder to deal with as there's no handshake for determining the other IP actually exists. Whereas with TCP syn cookies, that particular problem is totally solved. Also, any benefits of UDP in this case are totally negated because implementations "MUST" support both. Any client or server that only uses UDP is broken. So embedded devices and the other scenarios you mention have to handle both protocols, on a message-by-message basis. There's no case where this is beneficial. Oh, also, since most VoIP systems today rely on IP authentication, UDP combined with the SIP routing rules means almost all of them are trivially exploitable. Despite this being a rather obvious attack, I've yet to see any SIP stacks explicitly harden for this. Larger companies hope firewalling is good enough (hint: it's not really). Look up Cloudflare's handling of DNS-based DDoS's for another example of why it's a bad decision. AFAIK HTTP doesn't allow "triangle" paths, like SIP. That is, in SIP, A talks to proxy B, which talks to client C. Then client C sends directly back to A. Of course, in reality, everyone turns on record route to make it act sane, but it's one more thing that's in the protocol and is lying in wait to screw someone over or just make things more complicated than necessary. But in SIP, this is not only possible, it's celebrated and drawn into diagrams, showing off how fantastic an idea they think it is. These kind of things arise when people act clever when writing stuff out on paper. When you're just writing a spec, your imagination is the limit. Actual implementation considerations are a detail that doesn't bother you. Actually, SIP requires an AI to be properly implemented, as the RFCs suggest implementation "infer" the "intent" of messages, which sounds like a job for GAI. Likewise, comments in headers, headers in querystring, multi-protocol flip-flopping, inane rewrite-TCP-inside-UDP, etc. etc. are all just a few keystrokes away when you're making up a spec. After all, SIP even says maybe someone would use it to start a chess game, that's their actual example. Despite having "Call-ID" as a mandatory header, they want to make it clear they're not about just calls! Oh no, they've implemented a general purpose session protocol. Look up the RFC for SIP torture tests. They revel in the fact they've created a terrible grammar with special syntax for various headers (multiple headers are separate, unless they're Accept, in which case combine them into a single value). There's no need for that and it just shows what a terrible idea it is to have text protocols without strict grammars. For a humorous take on this: https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt In which he mocks the SIP design decisions, but in a very accurate way reflecting what real-world networks actually do. My favourite line: "But this is not the real world, this is the IETF".

MichaelGG 12y ago

The scenarios I worked on were for load balancers, proxies, and analyzers. All very high performance (at peak, 5TB/day of SIP on a single quad core processor). SIP parsing is terrible for this and leads to ugly hacky code. Same as HTTP (look at nginx's parsing code - all sorts of crazy compares). This is also why the HTTP replacement protocols ditched this nonsense. Yes, a lot of stuff came from HTTP, which likewise has no excuse other than copying previous mistakes (the date example being a prime example). Except, SIP isn't HTTP compatible, and no implementation is going to be sharing code. It'd beyond bizarre wishful thinking that an implementation is going to share any nontrivial amount of code. One of the folks from the RFC explained they aimed to make it HTTP compatible to use HTTP proxies, than gave up part way through but didn't fix up the rest of it. At any rate, you can blame SIP for it - no need to copy previous mistakes. And HTTP deserves a ton of blame, and I'd be absolutely surprised to find out that most software follows the HTTP spec. Most likely, they follow something sort of looking like HTTP, and test on the Internet to see which subset is actually being followed. Just like no one puts comments into email URIs because it's stupid. Fragmentation does _not_ need to be taken care of in protocol. IP already does fragmentation and it works. As I noted: 1-2% of all our customers had MTUs of ~576 bytes, so their SIP UDP packets were already IP fragemented. No one experienced problems with this, and some broken IP fragmentation issue would also affect TCP. UDP has a limit, but they could specify a switch to TCP at 64K. Could you clarify what you mean? UDP actually makes DoS harder to deal with as there's no handshake for determining the other IP actually exists. Whereas with TCP syn cookies, that particular problem is totally solved. Also, any benefits of UDP in this case are totally negated because implementations "MUST" support both. Any client or server that only uses UDP is broken. So embedded devices and the other scenarios you mention have to handle both protocols, on a message-by-message basis. There's no case where this is beneficial. Oh, also, since most VoIP systems today rely on IP authentication, UDP combined with the SIP routing rules means almost all of them are trivially exploitable. Despite this being a rather obvious attack, I've yet to see any SIP stacks explicitly harden for this. Larger companies hope firewalling is good enough (hint: it's not really). Look up Cloudflare's handling of DNS-based DDoS's for another example of why it's a bad decision. AFAIK HTTP doesn't allow "triangle" paths, like SIP. That is, in SIP, A talks to proxy B, which talks to client C. Then client C sends directly back to A. Of course, in reality, everyone turns on record route to make it act sane, but it's one more thing that's in the protocol and is lying in wait to screw someone over or just make things more complicated than necessary. But in SIP, this is not only possible, it's celebrated and drawn into diagrams, showing off how fantastic an idea they think it is. These kind of things arise when people act clever when writing stuff out on paper. When you're just writing a spec, your imagination is the limit. Actual implementation considerations are a detail that doesn't bother you. Actually, SIP requires an AI to be properly implemented, as the RFCs suggest implementation "infer" the "intent" of messages, which sounds like a job for GAI. Likewise, comments in headers, headers in querystring, multi-protocol flip-flopping, inane rewrite-TCP-inside-UDP, etc. etc. are all just a few keystrokes away when you're making up a spec. After all, SIP even says maybe someone would use it to start a chess game, that's their actual example. Despite having "Call-ID" as a mandatory header, they want to make it clear they're not about just calls! Oh no, they've implemented a general purpose session protocol. Look up the RFC for SIP torture tests. They revel in the fact they've created a terrible grammar with special syntax for various headers (multiple headers are separate, unless they're Accept, in which case combine them into a single value). There's no need for that and it just shows what a terrible idea it is to have text protocols without strict grammars. For a humorous take on this: https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt In which he mocks the SIP design decisions, but in a very accurate way reflecting what real-world networks actually do. My favourite line: "But this is not the real world, this is the IETF".