Re: Fwd: In the firing line

I wrote and Clemens Fischer forwarded:

>SIP was designed to handle the requirements of voice over IP
>signalling (by carrying an SDP payload) and instant messaging.
>Basically on the wire it looks a lot like HTTP, but requires a lot of
>email like headers ("From", "To", etc.) SIP addresses are of the form
>sip:[email protected], that is, they have a user and a domain part.

Just so people get more of a feel for what this looks like, here's
some examples:

Here's a Cisco phone registering the address [email protected] on the
server iagu.net, asking for all messages to be forwarded to
[email protected]:5060

REGISTER sip:iagu.net SIP/2.0
Via: SIP/2.0/UDP 203.32.153.142:5060
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
Date: Tue, 25 Mar 2003 04:35:14 GMT
CSeq: 102 REGISTER
User-Agent: CSCO/4
Contact: <sip:[email protected]:5060>
Proxy-Authorization: Digest 
username="andrewr",realm="iagu.net",uri="sip:iagu.ne
t",response="c2e84019fbe10d966b5297e153320b3e",nonce="f8bc87faeb27cac9303dd6f48c
dc023c",algorithm=MD5
Content-Length: 0
Expires: 3600

And the response:

SIP/2.0 200 OK
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 102 REGISTER
Date: Tue, 25 Mar 2003 04:35:14 GMT
Via: SIP/2.0/UDP 203.32.153.142:5060
Server: Iagu-Slipper/3.1r2
Content-Length: 0

(Note I omitted the previous Registration attempt that provoked a 407
response with the nonce in it. I also carefully selected an example
where the SIP address doesn't have a matching email address. :-)

Here's an INVITE (Call setup) being sent to a phone from an anonymous
caller. Note that although this is for a phone call, all the VoIP specific
parts are in the message body, defined as application/sdp (Session
Description Protocol). It could easily be message/external-body instead.

Note that the Via headers are somewhat equivalent to Received headers,
but they are actively used in the protocol - the return path for the
"200 OK" is determined from the "Via" headers [1], and then the three-way
handshake completes with an "ACK" sent over the same path as the "INVITE".

In the 200 response (think HTTP), a ";tag=" is added to the "To" header,
which the "ACK" must include. This prevents someone from attempting to
send an "INVITE" and an "ACK" without seeing the 200 response.

What this three-way transaction does is give you a return path to the
real originator that can't easily be faked [2] while still successfully
completing the transaction.

And yes, every SIP server I've come across does have anti-relay
provisions. :-)

[1] Note that a receiving server checks the top-most "Via" header and
adds "received=x.x.x.x:5060" if it's received from something that
doesn't match what the sender claims. Via headers are then stripped off
in the return path by the thing that added it. This allows devices
hidden behind NAT to learn what address is being presented to the
outside world, as the VIa header will contain (for example)
"sip:10.1.2.3.4:5060;received=203.32.153.69:5060" so it can then modify
subsequent outbound packets.

[2] OK, with in-line sniffers it could, and someone who is legitimately
in the path could have a fake hop behind them to confuse.
(Anyone remember kremvax? :-)


INVITE sip:[email protected] SIP/2.0
From: "anonymous" <sip:203.32.153.130>;tag=3F166394-2404
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 101 INVITE
Contact: sip:203.32.153.130:5060
Date: Tue, 25 Mar 2003 05:14:52 GMT
Expires: 180
Record-Route: <sip:sip.voip.iagu.net>
Remote-Party-ID: <sip:203.32.153.130>;party=calling;screen=yes;privacy=full
Timestamp: 1048569292
Via: SIP/2.0/UDP sip.voip.iagu.net:5060;branch=999b4622be6f192e6979e81a60328d18
Via: SIP/2.0/UDP 203.32.153.130:5060;branch=z9hG4bK14FC
Max-Forwards: 14
User-Agent: Iagu-Slipper/3.1r2
Allow: INVITE,OPTIONS,BYE,CANCEL,ACK,COMET,REFER,SUBSCRIBE,NOTIFY,INFO,UPDATE
Allow-Events: telephone-event
Cisco-Guid: 2335989559-1572278743-2270399157-581513226
Min-SE: 1800
Supported: timer
Content-Type: application/sdp
Content-Length: 426

v=0
o=CiscoSystemsSIP-GW-UserAgent 7721 6703 IN IP4 203.32.153.130
s=SIP Call
c=IN IP4 203.32.153.130
t=0 0
m=audio 19038 RTP/AVP 8 18 4 98 3 0 100 19
c=IN IP4 203.32.153.130
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:19 CN/8000

-- 
Andrew Rutherford      sip:[email protected]      244 Pirie Street
Iagu Networks          tel:+61-8-8425-2255       Adelaide SA 5000
http://www.iagu.net/   mailto:[email protected]   Australia