Theo's Blog

SIP URI syntax is broken with IPv6 & Generic URIs

theo@crazygreek.co.uk (Theo Zourzouvillys) — Fri, 06 Mar 2009 20:55:00 +0000

Well, actually, the way a bunch of commonly used URI schemes define their IPv6 syntax doesn't match what is allowed in the generic syntax defined in RFC 3986.

SIP, (as well as a number of other URI schemes) define IPv6 literal URIs to be enclosed in square brackets to differentiate them, for example:

sip:[XXXX:XXXX::XXXX]:5060

iax:[2001:db8::1]:4569/alice?friends

Presumably, this is because of the "host" ABNF rule defined in RFC 3986:

host = IP-literal / IPv4address / reg-name

IP-literal = "[" ( IPv6address / IPvFuture ) "]"

The problem with this is that the host rule is only used when the absolute-URI contains '://':

absolute-URI = scheme ":" hier-part [ "?" query ]

hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

authority     = [ userinfo "@" ] host [ ":" port ]

so URI schemes such as sip where the URI doesn't contain a ://, then an IPv6 address would instead match path-rootless:

path-rootless = segment-nz *( "/" segment )

segment-nz    = 1*pchar

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

pct-encoded   = "%" HEXDIG HEXDIG

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

reserved      = gen-delims / sub-delims

gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

Specifically, this means that only the following un-escaped characters are allowed:

A-Za-z
0-9
: @
! $ & " ( ) * + , ; =

Any other characters must be encoded using %XX format.

While this won't break SIP elements out there, one thing is will break is trying to use an IPv6 address literal somewhere where a generic URI is expected, for example:

Generic URI parser
XML Schema "anyURI" datatype
HTML href attribute

... and anything else that expects a URI.

Note that implementations of above may use RFC 2396 (and RFC 2397 to add support for IPv6 literals) instead.

The following other URIs schemes are also affected:

h323
im
mailto
pres
xmpp

It seems that most people think that RFC 3986 needs to be updated.

The original thread discussing this on sip@ietf.org.org can be found here.

SIP relay attack summary: It's a big User Agent FAIL.

theo@crazygreek.co.uk (Theo Zourzouvillys) — Thu, 05 Mar 2009 13:36:00 +0000

To summarise the document, it claims there are essentially 3 different attacks, all similar in the result - a 3rd party could use a victims valid credentials for authentication, resulting in - for example - the victim being charged for calls made by the attacker.

Attack 1: Direct Relay (fig 1)




      
                             bob              alice     +1-900-xxx
         proxy.com       @rogue.com        @proxy.com   @proxy.com
            |                 |                 |            |
            |                 |  INVITE F1      |            |
            |                 |---------------->|            |
            |                 |  200 OK F2      |            |
            |                 |<----------------|            |
            |                 |     ACK F3      |            |
            |                 |---------------->|            |
            |                 |                 |            |
            |                 |  media session  |            |
            |                 |.................|            |
            |                 |                 |            |
            |                 |  INVITE F4      |            |
            |                 |<----------------|            |
            |              modify               |            |
            |            the request            |            |
            |  INVITE F5      |                 |            |
            |<----------------|                 |            |
            |     407 F6      |                 |            |
            |---------------->|                 |            |
            |     ACK F7      |                 |            |
            |<----------------|                 |            |
            |              reverse              |            |
            |            the changes            |            |
            |                 |     407 F8      |            |
            |                 |---------------->|            |
            |                 |     ACK F9      |            |
            |                 |<----------------|            |
            |              modify               |            |
            |            the request            |            |
            |                 | INVITE(auth) F10|            |
            | INVITE(auth) F11|<----------------|            |
            |<----------------|                 |            |
            |      INVITE F12 |                 |            |
            |----------------------------------------------->|
            |                 |                 |            |

In this attack, the attacker sends an INVITE directly to the victim. The victim answers and the call starts. The attacker then forces the victim to send a re-INVITE: possible though session timers, or possibly through social engineering (e.g, getting the call put on hold).

Once the attacker receives the re-INVITE send by the victim, an INVITE is sent to the proxy of the service provider that the victim uses. The service provider will respond back to the attacker with a 407 along with a Proxy-Authenticate header containing a realm and nonce.

The attacker then copies the Proxy-Authenticate header in to it's own 407 response (to the in-dialog re-INVITE), which the victim receives. The victim then re-sends the re-INVITE with valid Proxy-Authorization header credentials.

At this point, the attacker receives the re-INVITE with credentials in, and adds into the INVITE it originally sent to the service provider.

Because these credentials are legitimate, and the information covered by the response in the authorization header is the same, the call is allowed.

Solution

The solution to this attack is really simple, and something that all UAs should be doing already: A SIP UA must limit the scope in which it will send authentication credentials.

While it seems like every UA out there should already be doing that, it would appear many don't.

Summary

This is a SIP User Agent security FAIL, not a problem with SIP.

Attack 2: Through outbound proxy (fig 2)




                                  bob                            alice
         p2.com        @rogue.com        proxy.com      @proxy.com
           |                |                |                |
           |                |  INVITE F1     |   INVITE F2    |
           |                |--------------->|--------------->|
           |                |  200 OK F4     |   200 OK F3    |
           |                |<---------------|<---------------|
           |                |     ACK F5     |      ACK F6    |
           |                |--------------->|--------------->|
           |                |                |                |
           |                |          mediasession           |
           |                |.................................|
           |                |                |                |
           |                |  INVITE F8     |   INVITE F7    |
           |                |<---------------|<---------------|
           |             modify              |                |
           |           the request           |                |
           | INVITE F9      |                |                |
           |<---------------|                |                |
           |    407 F10     |                |                |
           |--------------->|                |                |
           |    ACK F11     |                |                |
           |<---------------|                |                |
           |             reverse             |                |
           |           the changes           |                |
           |                |     407 F12    |     407 F13    |
           |                |--------------->|--------------->|
           |                |     ACK F15    |     ACK F14    |
           |                |<---------------|<---------------|
           |                | INV w/auth  F17| INV w/auth F16 |
           |                |<---------------|<---------------|
           |             modify              |                |
           |           the request           |                |
           |                |                |                |
           | INV w/auth F18 |                |                |
           |<---------------|                |                |
           |                |                |                |

So presuming we've got a well configured SIP User Agent that only sends credentials to 407 responses received through the proxy it's configured with, the second attack highlighted in the draft is a method by which the attacker can perform the same operation, but through the proxy that the victim uses, by sending a call to the UA through the proxy.

Of course, any sensibly configured outbound proxy would remove credentials at the edge of the network that relate to the realms that the administrative domain the proxy is in may generate, rather than leave them in.

Assuming a well configured proxy is at play, this leaves an attack where a SIP User Agent which has credentials for 2 authentication realms - lets say proxy.atlanta.com and proxy.billoxi.com may potentially be tricked into sending credentials for proxy.atlana.com through it's proxy.billoxi.com proxy, and therefore wouldn't be protected by the network stripping out the credentials.

Solution

As in Attack #1, a User Agent should simply ensure that the scope in which it will send credentials is limited. A UA registered with two providers should only ever send proxy authentication details to the outbound proxy those credentials have been configured for.

Summary

This is a SIP User Agent security FAIL, and not a problem with SIP.

Attack 3: Directed Response (fig 3)






                                 bob                             alice
         proxy.com     @rogue.com        proxy.com      @proxy.com
           |                |                |                |
           |                |  INVITE F1     |   INVITE F2    |
           |                |<---------------|<---------------|
           |         remove proxy.com        |                |
           |         from Record-Route       |                |
           |          and Via headers        |                |
           |                |            200 OK F3            |
           |                |-------------------------------->|
           |                |               ACK F4            |
           |                |<--------------------------------|
           |                |                |                |
           |                |          mediasession           |
           |                |.................................|
           |                |                |                |
           |                |  INVITE F6     |   INVITE F5    |
           |                |<--------------------------------|
           |             modify              |                |
           |           the request           |                |
           | INVITE F7      |                |                |
           |<---------------|                |                |
           |    407 F8      |                |                |
           |--------------->|                |                |
           |    ACK F9      |                |                |
           |<---------------|                |                |
           |             reverse             |                |
           |           the changes           |                |
           |                |             407 F10             |
           |                |-------------------------------->|
           |                |             ACK F11             |
           |                |<--------------------------------|
           |                |     INV w/auth  F12             |
           |                |<--------------------------------|
           |             modify              |                |
           |           the request           |                |
           |                |                |                |
           | INV w/auth F13 |                |                |
           |<---------------|                |                |
           |                |                |                |

If the attacker can get the victim to call the attacker through it's proxy and the proxy is victim is publicly accessible, then the attacker could theoretically remove any Record-Route and Via headers from the request, and send a 200 response directly back to the victim. As the call originally went through the proxy, the UA could conceivably think this call was secured, and thus when the re-INVITE is triggered, it would send the credentials.

Solution

As with both the other attacks, a User Agent should simply ensure that the scope in which it will send credentials is limited. A UA should never send credentials to in any request that is not within the scope the credentials have been provided for.

Similarly, it's common for a device to have an option similar to send in-dialog requests through outbound proxy (i.e, draft-outbound style routing), in which case even a badly written the User Agent is not vulnerable.

Summary

This is a SIP User Agent security FAIL, and not a problem with SIP.

Summary

In summary, I don't think this document presents any security issues in SIP itself, but does highlight and document some attack vectors that UA vendors should take on board when developing SIP User Agents, and a useful reminder to SIP service providers that you really need to really think about your network deployment (or pay me to do it for you).

Most specifically, a SIP user agent that is configured with proxy credentials should only ever send them in requests being transmitted directly to the outbound proxy the credentials have been provided for, and never to a 3rd party.

Service providers should ensure they remove authorization headers that relate to any realms they are administratively responsible for at the edge.

An important point in the above attacks is that a user agent appears to need to know when a request containing authentication is actually coming from it's proxy or not. In reality this is not the case, as the answer to the question of if credentials should be sent or not lies in where those credentials are going to be send to, not where the request for them came from.

Without sending all (including in-dialog) requests via an outbound proxy, it's not always going to be possible to tell when the next hop is really the proxy wanting authentication or not, specifically due to the fact that an in-dialog next hop may be a different hostname - for example sbc-13.b.london.edge.voip.co.uk - rather than the proxy itself - for example outbound.voip.co.uk.

The answer to this lies in (mutual) TLS between a SIP user agent and it's proxy, either TLS over TCP or more recently and cutting edge, DTLS over UDP. This allows for a client to be sure of where it's sending a request to before actually doing it, and thus that it doesn't leak it's proxy credentials when it shouldn't.

Until [D] TLS is universally deployed, a temporary workaround to this is ensure that the IP address you're sending to is in the SRV or A/AAA records of the proxy. While this is far from perfect, in reality it will work for most deployed service providers today. Note that if you do implement this, please remember to refresh the list based on TTL values in RRsets as well as the fact hosts may have both A, AAAA, and SRV records! and for goodness sake make the setting optional!

End-to-End & Multi-Hop proxy authentication

The above attacks don't cover end-to-end (WWW-Auth instead of proxy authentication), or multi-hop proxy authentication.

It's far harder to limit the scope in which the authentication should be released in these scenarios, as it's not a simple case of "only if sending to the proxy the credentials are for". Identity could be considered instead in these scenarios.

Although note that Identity isn't perfect yet - it has some issues with "baiting" - a subject for another day.

Another SIP vulnerability documented

theo@crazygreek.co.uk (Theo Zourzouvillys) — Thu, 05 Mar 2009 01:11:00 +0000

draft-state-sip-relay-attack-00 documents yet another vulnerability in SIP, this time allowing an attacker to use a victims credentials to send authenticated requests as the victim. This could be used, for example, to charge calls to the victim.

Any scalable solutions i've been able to come up with so far have been blown away by the fact the attacker can cause the target URI (as the victim sees it) to be whatever we want, as I just commented on sip@ietf.org:

Thanks for documenting this!

page 10:

It is worth noting that the protection
provided on the request URI is purely theoretical, as [RFC3261]
introduces an exception to the request URI checking required by
[RFC2617] in section 22.4:

Another important consideration to keep in mind while thinking about solutions is that the Contact header in the dialog creating request can be pretty much anything bob likes if he also adds a Record-Route header in, leading to the dialog target URI at alice's UA being whatever bob wants, and thus the Authentication header can be manipulated to contain whatever the attacker wants in the uri parameter. To explain - consider Figure 1 in the draft.

F1 could be sent by bob@rouge.com as:

INVITE sip:alice@proxy.com SIP/2.0
Contact: <sip:+1-900-xxx@proxy.com>
Record-Route: <sip:bob@rouge.com;lr>

thus, when alice creates the dialog, the remote URI will indeed be +1-900-xxx@proxy.com, and your in-dialog F10 message will be:

F10 INVITE Alice -> Bob

     INVITE sip:+1-900-xxx@proxy.com SIP/2.0
     Route: <sip:bob@rouge.com;lr>
     Proxy-Authorization: Digest username="alice", realm="proxy.com", uri="sip:+1-900-xxx@proxy.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543", response="3bea678acef9875433487f23a567d876", opaque="", algorithm=MD5
     Content-Type: application/sdp
     Content-Length:...

presto - the authentication header now even contains the URI you want to call. note that a re-INVITE could also be done to change the target URI a few times to get different Authentication headers with different URIs in, all legitimate.

As to the potential solutions: both only accepting from registered contact or any attempt at avoiding sending re-INVITE [1] are in my opinion unfeasible and broken - i'll have some thought on others, though :-)

~ Theo

1 - REFER is another in-dialog method that could be abused - an OOD REFER may be accepted with authentication by - for example - a PSTN gateway. Social engineering of alice could result in alice's UA sending a REFER that could then be used.

I've just been for a long run and thought about this, and not come up with even a half sane solution: blurgh.

bed.

SIP bug of the day: Cisco FAIL

theo@crazygreek.co.uk (Theo Zourzouvillys) — Wed, 04 Mar 2009 22:26:00 +0000

Vendors 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)

SIP Security - User Interfaces

theo@crazygreek.co.uk (Theo Zourzouvillys) — Wed, 04 Mar 2009 18:28:00 +0000

As SIP-enabled phones capable of receiving calls from callers with SIP URIs as identifiers, much thought needs to be given to how these identifiers (assuming they are verified) are rendered to end users.

It is common for a phone to render the "Display Name" in a SIP request on the phone's UI. This value is set by the caller themselves, an in the case where a caller is an attacker, can manipulate it to make the UI display a value of it's choice, for example:

From: "manager@hsbc.co.uk" <sip:attacker@evil.example.com>;tag=xxx

Every single SIP device I tested displayed this as manager@hsbc.co.uk on the screen.

Even more thought needs to be taken when allowing Call-Info. A picture of a padlock could be sent with Call-Info to render a picture of a padlock on the screen, lulling the user into thinking the call is secure.

Some people suggest instead you render the URI of the identity, but how do UIs render this?

From: <sip:manager%40hsbc.co.uk%00@evil.example.com>;tag=xxx

You guessed it, on the phone on my desk, I get:

manager@hsbc.co.uk

Ahem.

Identity in SIP is more than just technical solutions. User Interfaces need to be carefully considered.

Are you sure you really know what a sequence of characters is?

theo@crazygreek.co.uk (Theo Zourzouvillys) — Wed, 04 Mar 2009 14:22:00 +0000

Just incase you weren't too sure, RFC 3987 defines it for you:

sequence of characters: A sequence of characters (one after another).

ohh, really? Well, just incase you weren't sure, lets define a sequence of octets:

sequence of octets: A sequence of octets (one after another).

yeah, really

P2P Architectures (and Zebras)

theo@crazygreek.co.uk (Theo Zourzouvillys) — Mon, 02 Mar 2009 22:41:00 +0000

Gonzalo Camarillo has just submitted draft-iab-p2p-archs-00, an overview on P2P architectures:

In this document we provide a survey of P2P (Peer-to-Peer) systems.
The survey includes a definition and a taxonomy of P2P systems.  This
survey also includes a description of which types of applications can
be built with P2P technologies and examples of P2P applications that
are currently in use on the Internet.  Finally, we discuss
architectural tradeoffs and provide guidelines for deciding whether
or not a P2P architecture would be suitable to meet the requirements
of a given application.

The documents definition of a P2P system:

We consider a system to be P2P if the elements that form the system share their resources in order to provide the service the system has been designed to provide.

The elements in the system both provide services to other elements and request services from other elements.

and a real quote from the draft:

ZebraNet is a network used to track Zebras in the wild.

It contains zebras, so must be worth a read!

SIP & telephone numbers

theo@crazygreek.co.uk (Theo Zourzouvillys) — Fri, 27 Feb 2009 17:57:00 +0000

There seems to be a fair bit of confusion over URIs in SIP, specifically in the area of representing telephone numbers and dial strings. SIP implementers often don't provide a way of configuring the way telephone numbers dialed on phones are converted in SIP URIs, resuling in service providers blindly re-writing incoming URIs based on some (often dumb) algorithm. Annoyingly, SIP provides the mechanisms to represent to a server what it's trying to call without introducting ambiguity in requests, or requring logic in the server provider for re-writting dialed numbers unless required.

Before continuing, it's worth spending a few moments considering what a telephone number really is - or perhaps what it represents.

Let's assume my telephone number on the PSTN is +442079460000. The PSTN uses a numbering plan called E.164 which defines the structure of the numbers, including country codes.

In addition to the global E.164 numbering plan, there are a few other types. When you plus your PSTN phone into the socket on the wall, it is going to have a numbering plan. this varies from country to country, and also even from provider to provider in some countries.

As i'm (mostly) English, i'll use the UK numbering plan as the example here, although the country in question is irrelevant really for this discussion.

The UK numbering plan

Note that a lot of the old school bell heads won't agree with some of the following section - and isn't necessarily how other people would approach the same subject - as it's very IP/globally oriented. The telecommunications world is changing (much to the dismay of carriers that employ the very same bell heads), and with it the concepts of terms previously used in other ways in the PSTN world. For example, NANP uses the terms "Numbering Plan", despite the fact from what I can see it's both a numbering plan and a dial plan using my definitions of the terms explained below. Suggestions for better names on a postcard to theo@crazygreek.co.uk please!

UK phone numbers are split up into groups. For this discussion we only need to differentiate between these categories:

Geographic (01, 02)
Non-Geographic (03), VoIP & Corporate (05), Mobile & Personal Numbering (07), Freephone and Special Rate (08), and Premium Rate (09)
Operator Services (short code starting with 1 - e.g 100 for operator, 123 for speaking clock, 1471 for call return, etc)
Directory Enquiries (118xxx)
Emergency Services (999 and 112)

An important differentiation between the first two categories and the others is that the first two are part of the E.164 numbering plan, and thus the UK number 02079460000 is also part of the E.164 dialplan, as +442079460000, as +44 is the country code assigned to the UK.

All of the other categories are not part of the E.164 numbering plan, but can be reached from any UK phone line - so this is where dial plans come in. A dial plan and a numbering plan are 2 different things in my world. A numbering plan specifies how numbers are allocated (e.g, the UK numbering plan), and a dialling plan specifies what an end user actually dials on a phone to get to a number. A phone (as a logical concept) has a dial plan associated with it.

The third category of numbers, Operator Services are unique to an operator. If i dial 123 on my land line phone provided by BT, it's not the same thing as calling 123 on my mobile phone provided by Vodafone, as Operator Service numbers are unique to the operator.

In the UK, our directory enquiry services are available on 118xxx, and is indeed part of the UK numbering plan. Dialling 118500 will get you through to BT's directory enquiry service if you're on a BT provided phone line or a Vodafone one. However, again, they're not part of the E.164 numbering plan.

To consider why this is the case, think about this: 02079460000 is +442079460000 in the E.164 numbering plan. To call it from any phone in the UK, you could dial 02079460000. Using a phone in America, you'd dial 011442079460000, as '011' is the dial string used in America to indicate what follows is an E.164 number (minus the '+').

But if I wanted to dial BT's directory enquiries (reachable on 118500 from a UK phone), what would I dial in America? 01144118500? - no! that's 0118500, an invalid number in the UK 01 numbering plan (specifically, 0118 is Reading, a rather boring town which wouldn't really bother me if you couldn't call it, but i'm sure people living there might complain :-)).

Now, in the UK we also have 2 network features: 141 and 1470. Prefixing any call with 141 will cause your number to be withheld, and prefixing with 1470 will cause it to be released (assuming your default is to withhold you number). Both of these are dial plan features, as opposed to be any part of the numbering plan.

Back To SIP

Because SIP is an IP protocol and can (and often does) run over the Internet, it doesn't have the same physical properties the PSTN does. A phone call can be made using SIP from my laptop, and then the next day using the same SIP account from somewhere in America.

So, when I dial a number into my SIP phone, what should the phone do with that number, and how does it indicate to the SIP service provider it's sending the call to?

Following the End-To-End principle that we all hold so dear to SIP (cough, splutter), the idea as that a SIP phone should be configured with a dialling plan, that takes the input the user has dialled, and converts it into something that the service provider knows what to do with, without any configuration on it's part.

However, how the URI is then represented in a SIP request URI is where confusion arises.

Firstly, let's assume we're talking about the PSTN here, and calling numbers on the PSTN.

The tel / user=phone approach

A SIP device can often be configured with a dial plan (also known as a digitmap). One of the reasons for this is to allow a SIP device to dial as soon as a number has been entered, rather than needing to wait for a user to press the "dial" button to place the call. It also allows a user to configure how it translated the number dialled into a number within a given numbering plan.

The dial plan configured on the phone can then modify the input string dialled by the user, and convert it into a telephone number that is globally unique. There is a URI scheme defined by the IETF (RFC 2806) to indicate a telephone number, "tel". In it's most simple form, a tel URI contains just an E.164 number. So, if I dial 02079460000 on my phone, the dial plan configured on it would convert that to call +442079460000, and request line could be:

INVITE tel:+442079460000 SIP/2.0

However, SIP URIs also have a way of representing a tel URI while being a valid SIP URI. A user=phone parameter in the SIP URI indicates that the user part of the URI (i.e, the bit between the "sip:" and the @) is actually a telephone number (the whole of the "tel:" URI without the leading "tel:"), as defined in RFC 2806. So you could instead send:

INVITE sip:+442079460000@voip.co.uk;user=phone SIP/2.0

Which is identical to the first example, except asking voip.co.uk to terminate the call rather than wherever you're sending the request to.

In order to be globally unique, a number needs to be scoped to a particular context (think about different numbering plans). A "phone-context" parameter of the tel URI defines the scope that the number is valid within. The default context of a tel URI is the global one - i.e, E.164, and the number itself must always be prefixed with '+'. The context changes the meaning of the number to indicate that it is valid within the environment where the local entities global phone number starts with the given string.

So, to call a number that is not in the E.164 context, we need to append the right phone-context. In the case of 118500 (a UK directory enquires service), it is available anywhere in the UK. Thus, a good phone-context would be "+44":

INVITE sip:118500;phone-context=+44@voip.co.uk;user=phone SIP/2.0

or it's tel URI brother:

INVITE tel:118500;phone-context=+44 SIP/2.0

Again, this would presumably be done by configuring a dial plan on the phone itself.

In order to handle privacy (such as 141 and 1470 in the UK), a SIP user agent must populate the Privacy header with the values it wishes to use itself rather than including the prefix in the number sent to the service provider. A dial plan configured on the phone could be utilised to do this. So dialing '14102079460000' should result in:

INVITE sip:+442079460000@voip.co.uk;user=phone SIP/2.0

Privacy: xxx

Note that although RFC 2806 has been updated by RFC 3966, RFC 3261 (the core SIP spec) references 2806. Specifically, RFC 2806 is ambiguous as to wether the "phone-context" MUST be included; In one paragraph it says it SHOULD, and another it says MUST. RFC 3966 updates for the inclusion of a phone-context parameter to be MUST.

The user=dialstring approach

Assuming the SIP device isn't smart enough to be configured with a dial plan - or perhaps it doesn't want to be - and wishes to offload the dial plan handling the network, we need some way of indicating this.

Luckily for us, RFC 4967 provides a mechanism for exactly that. The server can then apply rules configured in "the network" for the number.

Note that a dial string URI MUST contain a phone-context parameter, so the question then arises what the value of this should be. While it depends very much on a deployment by deployment basis, I see 2 general ways of handling it:

A set of pre defined contexts are created, and the user selects the one they want. For example, uk.dialplan.voip.co.uk could be the standard UK dialplan defined above.
Each user can create their own context - presumably under the domain of the service provider. For example, I use theo.dialplan.voip.co.uk. I then configure this context using tools provided by VoIP.co.uk

I then configure my phone to use "user=dialplan", and tell the phone which context i wish to use - let's say uk.dialplan.voip.co.uk.

Thus, if I wanted to call 118500 (UK directory enquiries), it would be sent as:

INVITE sip:118500;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0

Similarly, calling my London number 02079460000:

INVITE sip:02079460000;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0

an international call would be:

INVITE sip:0015001234567;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0

Using our withhold CLI feature also works using this approach, so I could call my london number while requesting the network withholds my number by indicating it in the dial string, assuming the uk.dialplan.voip.co.uk dial plan has been suitably configured:

INVITE sip:14102079460000;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0

Of course, in reality, very few SIP devices are ever configured with dial plans, and most networks don't even support phone-context! Generally, when you send a call to a service provider, it will currently perform analysis of the number and look at settings for the user trying to place to call to extract what it means. While this works most the time, it does require logic in the network, which means you're never really sure what the network is doing for you.

urn:sos

One issue with phone-contexts is they are not aware of your current location, and some - in reality one - location really needs to know where you are: the emergency services.

When you dial 999 (or 112, or 911 perhaps), you really want to speak to the emergency services near where you are, not wherever your phone-context is configured!

So, to let the network know that, a special URN service has been defined in RFC 5031. When your phone detects you've called the emergency services (by looking at the number you dialed), it would convert that to a emergency services URN:

INVITE urn:service:sos SIP/2.0

You can also qualify it with a more exact service - as some countries have different numbers for different services - for example:

urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas

See the IANA registry for all the currently registered services.

The idea with these is that the SIP proxy receiving the request would use location based information to route the call to the correct place.

ENUM

ENUM provides a few funky solutions to some problems in SIP.

A NAPTR lookup could allow a phone to look up how many digits are needed to reach a valid number as the user is dialling by using Ray Bellis' Send-N draft. By using phone-context with DNS entries, even a local phone-context can also be handled this way.

Linked Numbering Schemes

It's common on a fixed PSTN line to be able to dial a local number without including the full prefix, for example, if I had the telephone number 02079460001, I could call 02079460000 by dialling 79460000. This is simply a feature of a phone context. Using user=dialstring, you could either set the context to the global number you're calling from, i.e:

INVITE sip:79460000;phone-context=+4402079460001@voip.co.uk;user=dialstring

or set the context to be a dialplan that has been configured to handle that, perhaps:

INVITE: sip:79460000;phone-context=london.uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0

draft-zourzouvillys-sip-via-cookie-01

theo@crazygreek.co.uk (Theo Zourzouvillys) — Wed, 25 Feb 2009 06:24:00 +0000

I've submitted a draft-zourzouvillys-sip-via-cookie-01, which addresses typos and feedback from people, although the underlying mechanism has not changed at all.

The new -01 draft does however contain some actual calculations on the extent of the problem, and as such i've upated the abstract to contain some fearmongering text :) ...

This document addresses a vulnerability in publicly accessible SIP servers (servers includes both UASes and proxies) that enables them to be used as an amplifier in an untracable reflected denial of service attack. The amplification ratio is between 1:10 to over 1:350 in both packets and bytes.

Discussion in IETF SIP working group has been good so far, and the draft well received.

Feedback, as always, most welcomed.

Addressing an Amplification Vulnerability in SIP Servers

theo@crazygreek.co.uk (Theo Zourzouvillys) — Fri, 20 Feb 2009 19:05:00 +0000

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.

SIPit 23 Survery Notes

theo@crazygreek.co.uk (Theo Zourzouvillys) — Fri, 24 Oct 2008 00:59:00 +0000

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."

Today's wise words

theo@crazygreek.co.uk (Theo Zourzouvillys) — Sat, 11 Oct 2008 17:24:00 +0000

Julie Meyer's great talk on The Future of Entrepreneurship at FOWA London '08 has this poignant quote in it, that everyone should think about long and hard:

"Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness that most frightens us. We ask ourselves, Who am I to be brilliant, gorgeous, talented, fabulous? Actually, who are you not to be? You are a child of God. Your playing small does not serve the world. There is nothing enlightened about shrinking so that other people won't feel insecure around you. We are all meant to shine, as children do. We were born to make manifest the glory of God that is within us. It's not just in some of us; it's in everyone. And as we let our own light shine, we unconsciously give other people permission to do the same. As we are liberated from our own fear, our presence automatically liberates others."

-- Marianne Williamson

The problem with credit ...

theo@crazygreek.co.uk (Theo Zourzouvillys) — Sat, 11 Oct 2008 16:53:00 +0000

... is that it's getting really hard to live life without it.

A few months ago my car broke down. I phoned up the AA, who arranged for it to be towed to the garage, and for a rental car for me for a few days. Shortly after, I got a call from Avis, who told me they needed my credit card details so they could take a deposit for damages, fuel, etc.

I gave them my Maestro card number - and they said that they only take Visa or Mastercard, not Maestro. So, I tried to give them my Visa Debit card. They wouldn't have any of that, either! Only credit, not debit cards accepted here, no sire. On asking why, they said "it's company policy".

Last week, I used my T-Mobile SIM card in my laptop to try to read a message on Facebook. It told me that there were parental controls (!) in place and I would need to remove them before I could access the site. So, I click on "remove content block", and a page later get asked for credit card details.

Guess what? Maestro doesn't work, Visa Debit doesn't work, and neither does my prepaid credit card from virgin.

So there are now 2 reasons i've needed a credit card, despite being lucky enough to have enough cash in my bank to not need one.

While credit cards may provide purchase protection, they're also fostering the deep rooted attitude towards credit so many people in the UK and America have today.

Mortgages, HP, car finance, credit cards, bank loans, pay advances - all instruments of the current "financial crisis" - although I don't think it's a crisis any more than capitalist punishment for being greedy bastards. all of us - not just the bankers.

Avis & T-Mobile are just as much to blame for the economy being the way it is right now as anyone who is in negative equity.

The national average for salary p/a is 23,746 GBP. After paying tax at code 474 and national insurance, that's 1,495.48 per month.

Assuming you could somehow live off half of that, then you could save 8,972 a year. That's 22 years of saving and living off an impossible amount to save 200,000 - the price of a semi-decent house outside of home counties.

Ohh, and hang on - we've just spent 22 years saving - we've not been able to go on holiday, or more importantly pay for a pension. Or pay council tax at perhaps 1000/year!

Houses are too expensive because we've got too many people and not enough land. To reduce house prices, we either need to have less people in the UK, or find more land to build on. We actually have plenty of land that's not built on, but it's mostly being used for farming & agriculture - a noble and important part of our economy, unless we want to dig ourselves into holes for the future by relying on other countries to give us food. Because we joined Europe and had a shoddy immigration policy for so long, we're probably stuck with the population as it is.

So i'd like to propose another solution: we swap some of the Icelandic debt in return for part of their country. We can defrost the land, and then provide it to British people for building houses on. The economy would boom due to all the houses being built, will generate lots of jobs due to all the building and staffing new high streets (which Icelandic companies already have experience in running), house prices in the UK would be in less demand, there would be less people in the UK, and as a result, house prices here would fall.

I should become a politician.

Differences between SIP and HTTP

theo@crazygreek.co.uk (Theo Zourzouvillys) — Sat, 11 Oct 2008 15:22:00 +0000

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 for session 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 and server.

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.

Day 3: Niagara Falls - Sodus Point, NY - Sackets Harbour, NY

theo@crazygreek.co.uk (Theo Zourzouvillys) — Wed, 01 Oct 2008 06:06:00 +0000

We awoke to an amazing view of Niagara Falls out of the hotel room window:

After an expensive breakfast at the Marriot ($20 each!), we left the hotel at about 0940, for a quick trip (~5 minutes!) down to the falls to grab the obligatory photos next to the falls...

and we headed back into the USA, after a very rude immigration officer (on the states side). After getting 2 very polite ones, I was starting to wonder what all the fuss people make about them was about - but now I understand!

Leaving Niagara falls we head east along Lake Ontario, and I start to see what I came here for ... endless trees!

After driving for a while through stunning scenery, we arrive in Rochester, NY - which is mostly uninteresting, except a huge Kodak building which was their HQ, now a museum - and continue until we make a stop at an old lighthouse, in Sodus Bay. Inside the lighthouse is a great little collection of local history, and the staff there were very interesting. Sadly, the weather was awful so the view wasn't that great.

We ended up in a quaint little town called Sackets Harbour at about 2000, and stayed in the hotel there for the night.

View Larger Map

Day 2: Shipshewana - Niagara Falls

theo@crazygreek.co.uk (Theo Zourzouvillys) — Sun, 28 Sep 2008 06:00:00 +0000

Awoke to the most beautiful view of Amish countryside and typical American barns.

Went to the Menno-Hoff -an Amish, Mennonite, Hudderite history - such a nice life they lead these days, shame I can never become Amish (i'd need to believe in god, for starters!).

Went to shops, found presents for one of the kids and jordan. After an amazing drive through some Amish communities, we drive into Ohio.

Ohio appears to be the land of absolute nothingness. Toledo was pretty un-interesting, and Cleveland even less so. Just a pretty shoreline onto lake Eire, with a bunch of nice houses.

so, straight out of Ohio and into Pennsylvania.

Then long drive to Niagara Falls.

We pre-booked a room at the Marriott in Niagara Falls, and arrived at about 2200 Local time. The town looked like it was bustling with tourist kitcheyness, so decided to go and explore some. A few drinks in a bar with very good live music, and back to the hotel at 0045 with alarm set for 0930 rise!

Perhaps someone could tell Boris to ask the Canadians for our routemasters back. This photo was taken this evening here in Niagara Falls. Thieving bastards!!

Tomorrow's plan: Head in the general direction on Maine!

View Larger Map

Day 1: Bicester - London - Chicago - Shipshewana

theo@crazygreek.co.uk (Theo Zourzouvillys) — Sat, 27 Sep 2008 04:31:00 +0000

After staying awake all of last night to attend to unfinished business, I was already tired when at 0630 I phoned for a taxi to take me to the train station for the 0710 train. "Sorry love, we're fully booked until seven thirty!". Bollocks.

A brisk walk to the train station later, a 50 minute journey into Marylebone, 2 stops on the Bakerloo to Paddington, then straight on the Heathrow express for 15 minutes. New record from Bicester North to Heathrow T3: 88 minutes including the walk from my house! Who said public transport in the UK sucks?

Despite all the troubles with air traffic control around London today, the Virgin flight left on time at 1115. Almost fell straight asleep, although I woke up about 2 hours into the flight feeling really hot and sweaty, light headed, and feeling like I was going to throw up. Now I fly regularly for periods longer than the 2 hours into the flight i was feeling like this, and most curiously, the only other time i felt like this from travelling was on my last return trip from America over 5 years ago! I put it down to food poisoning that time (never trust the salmon!), but I didn't even eat anything this time!

8 hours and 20 minutes after take off, and a good few hours sleep later and 72 pages through Small is the new Big by Seth Godin, the plane lands in Chicago.

Dreading the normal immigration interrogations, I was pleased to be directed toward a immigration officer who was not only polite and chatty, but also smiled. Yes, can you believe it, she smiled. Shocking! While she was very friendly in her chatting, it was obvious she was asking trying to establish if I was actually a risk to leaving

After meeting up with Ryan, grabbing a Starbucks, and taking a short taxi ride to Alamo, I sign some forms, pay some money (250 GBP) then get told "pick any car you like form that lot. The keys are in the ignition". Hmm!

So, a rather nice looking cream Jeep Liberty later (22 MPG!!), and i'm getting lessons in how to drive again. Well, how to drive an automatic, and what P, R, N, D, 1 & 2. does! A quick few reminds that i need to drlve on the right, and we're all set.

GPS programmed. Destinaiton: Buffallo, NY. Tentative plan: Drive to Niagara Falls, then up to Vermont to see the pretty red leaves.

While stopped at a Burger King for a late lunch, Ryan noticed that there is an Amish community not far away from our tentative plan to get to Niagara Falls. I've always been most curious of the Amish; Their lifestyle seems to very attractive to me, so attached and dependant on technology.

Detour arranged, and we end up in a little town called Middlebury at about 2030 (we're in EST now), and it's dark. Getting out of the car, we notice a whole load of youngsters - all smoking, and chatting away. Oddly, in England, Paris, or Berlin, this sort of crowd would have seemed a little threatening. Yet, here in the middle of Amish paradise, a group of a dozen teenagers just didn't seem in the slightest threatening. At all.

After asking the woman in the gas station (seem, i'm taking the talk already!) for some hints on a nice hotel, she pointed us down a street, and said "that'a'way! Careful of the bogies on the bikes!". Perplexed, we drove off in the direction she pointed us, keeping a close guard for bogies, or even just bikes.

A few minutes later, coming in the other direction is a horse drawn cart, with 2 Amish guys sitting on the back! They have a red flashing light attached to the back. One of them flashes a white light at us, obviously to say we're here!". Travelling just over 3 miles, we must have passed at last a dozen of these going in both directions!

Finally, we find a hotel called Farmstead Inn, by a brand called Trading Place. Only one room left, so I get a double bed, and Ryan gets a "cot", as the amricans call 'em

I've had a total of 4 "wow, you have such a cool accent" comments today.

Sadly, we'll be missing the local attractions: Wednesday for the local weekly hay & livestock, or horse, tack & pony auction on fridays. Damn! There is a whole 3 things listed to do after 6pm here, wow!

All in all, a great first 1/2 day!

I'll uploads the photos tomorrow, I didn't get to grab any this evening, as it's pitch black outside!

View Larger Map

American Road Trip

theo@crazygreek.co.uk (Theo Zourzouvillys) — Tue, 26 Aug 2008 20:00:00 +0000

Ever since a funny set of circumstances left me with a copy of the book Road Trip USA, i've been attracted to the thought of seeing America from the Highway.

The stunning coastlines of the Jersey Shores, the fertile fields of Pennsylvania Dutch country, the thick forests and tiny mountain towns on the old frontier, the Ozarks, the crests of the Appalachians (one day I will hike the trail from Springer Mountain to Katahdin, ohh yes), the Natchez trace, the deep dark Mississippi, the kitsch of Memphis, ohh my, how the list goes on!

Now wonder so few American's leave the country, they don't need to - everything is right at their doorstep!

I'm not particularly interested in big cities - although Chicago and Boston both seem to interest me; Chicago for the architecture, and Boston for Crane, Pool, & Schmidt - i'm far more drawn to the history of the USA, the countryside, the sheer vastness it exudes to a foreigner.

Perhaps the vastness is not really so great, perhaps the roads are just very long and very boring - but without trying, i'll never know!

So, today I booked just under 3 weeks off work for the end of September. I'm flying to New York, where i'm renting a car. The plan - which is really just a guide to get me going, not an itinerary - is to drive west from NY through Dutch Country, meeting US-50 on the West Virginia/Ohio border, and then follow the US-50 all the way through to St Louis.

I've arranged with a friend to meet in St Louis, and he's booked a week of work, so we're going to explore the south central states together - from St Louis (where Ryan lives) the plan currently involves a brief overload of kitsch at Branson, MO; then down through the Ozarks and along the Mississippi until we get to Jackson, MS, then follow the Natchez Trace up to Nashville, TN before heading back to St Louis.

That said, we've got 9 days from when we leave St Louis until we need to be back there as Ryan needs to work. So we'll probably not do the whole loop, and up up skipping some chunks in order to get back on time.

Once back, i'm heading off on my own to Chicago for a day or two, then following Lake Michigan east until I hit Niagara, then (time permitting) up to New Hampshire, before following the coast down through Boston to get back to JFK in time for my flight home.

View Larger Map

Total mileage, according to Google maps is around 4100 miles. Over 21 days, that's around 200 miles per day - probably around 4 hours - the equivalent of driving Oxford to Plymouth each day, or in total a trip from Oxford to Athens and back.

In comparison, last summer from Oxford to Greece and back, I did a total of 4000 miles in 50 hours over 3 days. So at least I know I can do it :-)

View Larger Map

I'm strangely excited about travelling alone. Normally, I travel with friends; i've been told the Americans are very friendly and strike up conversations easily - unlike the British, who look at you like you've just mugged them if you say even hello! these days. I've got a lot of pre-conceptions of Americans (I meet a fair few with work), so it will be interesting to see what the American equivalent of a Devon bumpkin is :-)

America, here I come - Just after a quick game of wif waf!

ps: if anyone fancies joining me for a few days (or lives en-route), let me know!

New blog

theo@crazygreek.co.uk (Theo Zourzouvillys) — Tue, 26 Aug 2008 16:03:00 +0000

Over a year since my last post! No change then - seems to have been a common pattern over the last 10 years.

I've decided that maintaining my own blog software is far to much hassle, so am trying out blogger's own static upload features with my own template. Seems like a far more sensible plan than using some crappy PHP software that needs ot be kept up to date :-)

The old content is still at http://crazygreek.co.uk/content/blog, the new URL is http://crazygreek.co.uk/blogger/ - although i've modified the old feed URL to point to this one.

Theo's Blog

SIP URI syntax is broken with IPv6 & Generic URIs

SIP relay attack summary: It's a big User Agent FAIL.

Attack 1: Direct Relay (fig 1)

Solution

Summary

Attack 2: Through outbound proxy (fig 2)

Solution

Summary

Attack 3: Directed Response (fig 3)

Solution

Summary

Summary

End-to-End & Multi-Hop proxy authentication

Another SIP vulnerability documented

SIP bug of the day: Cisco FAIL

SIP Security - User Interfaces

Are you sure you *really* know what a sequence of characters is?

P2P Architectures (and Zebras)

SIP & telephone numbers

The UK numbering plan

Back To SIP

The tel / user=phone approach

The user=dialstring approach

urn:sos

ENUM

Linked Numbering Schemes

draft-zourzouvillys-sip-via-cookie-01

Addressing an Amplification Vulnerability in SIP Servers

I don't like elephants.

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

Outlook

SIPit 23 Survery Notes

Today's wise words

The problem with credit ...

Differences between SIP and HTTP

Similarities

SIP has a similar looking textual representation to SIP.

Both have 3 letter response codes in responses.

Both have normative references to rfc2617.

Differences

SIP initiates sessions. HTTP transfers data.

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

A transaction in SIP can span multiple messages

SIP has provisional responses

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

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

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

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

SIP is broken. HTTP ain't.

Day 3: Niagara Falls - Sodus Point, NY - Sackets Harbour, NY

Day 2: Shipshewana - Niagara Falls

Day 1: Bicester - London - Chicago - Shipshewana

American Road Trip

New blog

Are you sure you really know what a sequence of characters is?