endors that don't provide me with an email  address of an english speaking human point of contact that can handle protocol bugs and isn't a front desk ticket person who has no idea what i'm talking about or tries to tell me to use another protocol like h323 instead can get their bugs stuck here instead!

Call from an E1:

INVITE sip:xxxxxx@X.X.X.X SIP/2.0

To: <sip:xxxxxx@X.X.X.X>

User-Agent: Cisco-SIPGateway/IOS-12.x

Our SIP server returns a 302 with new Contact:

SIP/2.0 302 Directed

Contact: <sip:Y.Y.Y.Y;param>

Server: InUrSIPPacketzRedirectingUr/INVITES

New INVITE following the 3xx FAIL:

INVITE sip:Y.Y.Y.Y;param SIP/2.0

To: <sip:@Y.Y.Y.Y>

User-Agent: Cisco-SIPGateway/IOS-12.x

Anyone from Cisco reading (and i know you do) - please can you get someone to fix it: I gave up trying to get bugs in your stacks fixed a long time ago :-)

Cisco IOS Software, 5350 Software (C5350-JK9S-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)

I don't like elephants.

There has been a great big elephant sitting in SIP that no one has wanted to talk about, for a long time.  Problem is, I don't like elephants.  They scare me.

People that are not intimate with SIP seem most surprised that a publicly accessible SIP server can commonly be used as an amplifier in a reflected denial of service attack.  They shouldn't be.  It's been like that forever.

So after years of ignoring the elephant in the room, i've tried to start tackling it, and have submitted some discussion on the matter along with an potential solution draft-zourzouvillys-sip-via-cookie-00.

It's not a complete solution to address all of the issues, but it brings UDP in line with stream based (and DTLS) transports so we can build a solution on top of this which mitigates the issues with in-dialog initiated attacks and RTP steering.

I AM THE SCARE MONGER, AND I BRING YOU ..... SCARES!

Until the problem this draft is trying to solve is fixed, any publicly accessible SIP server listening on UDP can likely be used as a amplifier in a reflected denial of service attack.  And that's bad, for all of us on the internet, not just the SIP world.  It means a SIP server can be used by an attacker as to amplify an attack against non-SIP infrastructure - that could be a web server, router, DNS server, or anything else an attacker so chooses.

By amplifier, we're talking one spoofed UDP request sent by an attacker resulting in 11 UDP responses sent to the victim (combined with other attacks, the pathological case results in ~35 UDP packets being sent to the victim from a single one by the attacker, along with a significant number of RTP packets).  Neither the victim nor the attacker need to have an account with the SI P server ("SIP server", for example, could be an asterisk install or just a bog standard SIP phone) - it just needs to be accessible and process requests statefully (and most do).

Ohh, and because it's UDP, it's not possible to trace the attacker, meaning we can't even find them and shut them down. woo.

Outlook

In the longer term, we've still got a few other elephants that need talking about: RTP target verification and Contact/Route validation for dialog creation are just two that can currently be abused for some potentially similarly scary attacks, and need to be solved rather than ignored.

Note that none of this is new.  This kind of feels like DNS all over again :-)

ho hum.

Robert Sparks has released the results of the survey of implementations taken to the last SIPit.

While not very much comes as a surprise, i'm particularly happy to see this:

"Many teams expressed intent to implement outbound and gruu once something was published as an RFC, and a strong unwillingness to even try until that happens."

Also good to see 2 XCAP servers.  I was starting to wonder if anyone would implement it :-)

This is a little worrying, though:

"The only people in the room who had even read the sip-config framework documents are regular IETF participants. Even fewer had read sip-consent or session-policy."

I was recently asked to justify my smug all-knowing grin when I was recently told that "SIP seems as simple as HTTP". 

I can understand how someone who has seen a few SIP messages in a book or in tshark can come to that conclusion, or perhaps even read a summary in a SIP book.  But, that's where the similarities end.  As soon as you start to deal with SIP at a protocol level, you'll come to realise why it's such a different beast from HTTP.

Similarities

SIP has a similar looking textual representation to SIP.

Caveat emptor: they're actually rather different - a validating SIP header parser will not parse HTTP, and vise versa.

Both have 3 letter response codes in responses.

However a response code in HTTP doesn't mean the same thing in SIP.  Both sit in entirely difference namespaces.

Both have normative references to rfc2617.

Except functionality like nonce counts, multiple proxy hops, and Authentication-Info are very confused in SIP.

Differences

SIP initiates sessions.  HTTP transfers data.

This is the key one.  HTTP was designed as a transfer protocol.  SIP was designed forsession initialisation.

SIP is for signaling, and isn't designed for transferring the data for the session itself.  RTP, MSRP, and XMPP are all examples of the session transport.

HTTP has a strict client/server model.  In SIP, the UA is a client andserver.

A SIP client is schizophrenic.  One second it's a client, then before it knows it, it's a server!  This is an important part of SIP - sessions are bi-directional.  All agents are both client's and servers.

A transaction in SIP can span multiple messages

Some of which are hop-by-hop (ACK to IxT failure), others are end-to-end (ACK to IxT 2xx).

Infact, SIP has a fairly complex state machine.  HTTP doesn't.  A Request results in a response.  Simple!

SIP has provisional responses

That can go on for an age in SIP.  Resources in a large scale SIP platform need to be carefully optimised to handle the very common case of a request waiting a very long period of time for a response - for example while a user's phone rings.  Because of this, provisional responses are sent before the final one.

SIP R-URI's can be modified as they traverse "the network"

When a SIP message is sent out from a UA, it only really knows it's next hop (excluding RRiing).  Each hop then takes responsibility for passing it on to the next hop - and indeed may even change the real target as it progresses.

HTTP on the other hand doesn't generally change the URL (front end reverse proxies excluded) without doing some nasty hacks like wireless portals, MNOs, and hotels tend to.

SIP messages are processed on a hop by hop basis.  HTTP can stream responses back.

A SIP message goes from hop to hop, completing each hope before continuing to the next.  Imagine in HTTP downloading the entire file to the proxy before you could start to download it to the web browser!

This all stems from the fact SIP only handles signaling, so it contains only (relatively) small messages.  HTTP on the other hand has no real limits on response size.

HTTP provides an entire architecture for caching.  SIP doesn't know anything about a caching proxy. 

Even a non-caching (pass through) HTTP proxy has very few similarities to a SIP proxy.

SIP doesn't know anything about caching, nor would it be valid to cache a response and provide it to something outside of the transaction.

SIP can (and most commonly does) run over unreliable protocols.

HTTP requires a reliable transport.  Congestion control is handled at the transport level.

SIP is broken.  HTTP ain't.

SBCs, HERFP, DTMF, identity - it's all rather broken in SIP.  HTTP seems to be fairly clean in it's implementation - SIP is far from it.

I'm still waiting for one person to tell me a single part of SIP that isn't broken in one form or another.  And yes, I can use the forking card when I see fit :-)  answers on a postcard to theo@crazygreek.co.uk please.