Subject: Question about media desinations

From: "Andrew Chalupka" <[email-masked]>
Date: Tue, 8 Feb 2000 13:55:25 -0500

Hi all,

Apologies if this question isn't appropriate for the SIP list...

Assume a user, "caller", initiates a SIP call with a second user, "callee",
through the usual means (INVITE, 200 OK, ACK).  During this message
exchange, each end speficies the IP address and UDP port number(s) to which
the other end should send his audio stream.  Would it be a violation of the
SIP standard for one of the participants to send his audio stream to a third
party (say to a server which might transcode the sender's audio packets into
a format the other end can understand) and then have that third party
forward the packets on to the appropriate destination?

Section B.2 of RFC 2543 (pg 138) mentions...

"For receive-only and send-or-receive streams, the port number and address
in the session description indicate where the media stream should be sent to
by the recipient of the session description, either caller or callee."

...which isn't as strong as saying the port-address pair supplied by the
other end *must* be used.  

Any clarifications?

- Andrew

---

From: Billy Biggs <[email-masked]>
Date: Tue, 8 Feb 2000 14:06:07 -0600

Andrew Chalupka ([email-masked]):

> [...]  Would it be a violation of the SIP standard for one of the
> participants to send his audio stream to a third party (say to a server which
> might transcode the sender's audio packets into a format the other end can
> understand) and then have that third party forward the packets on to the
> appropriate destination?
> 

  Maybe I am misunderstanding your questions, but we frequently send SIP to a
proxy which is different then the UA we exchange media with.  So, yes.

  This brings up an interesting issue that I think is relevant to the sip list.
Is there any sane policy that a client can enforce to prevent unsolicited audio
to be played?

  One policy we came up with was that a client should only accept audio from
whomever it is sending audio to.  This policy seems to be broken.  I think the
example Andrew gives above is I think close.  What if we're receiving audio
locally, but our audio is sent to a third party and then sent to the far end.

  Given that there is no required method of dictating where audio will come
from, a client is therefore in my eyes forced to accept and play whatever audio
receives.

  Following on that, once audio is being received, in my mind there isn't
anything stopping someone from blabbing into an existing conversation.  Since
you can't be assured about where audio is to come from, is a sane policy that
once you start receiving audio from a foreign party that it must always come
from that host?

  I don't think that works either.  Why can't you have hold music come from a
different host while still receiving audio?  No re-INVITE required...  In that
case, you can't even be assured of a common SSRC.

  So, what's stopping a haxor like me from strobbing a gateway with random
audio... ??

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: "David Oran" <[email-masked]>
Date: Tue, 8 Feb 2000 15:19:32 -0500

>   So, what's stopping a haxor like me from strobbing a gateway with random
Crypto.

---

From: Billy Biggs <[email-masked]>
Date: Tue, 8 Feb 2000 14:47:18 -0600

> >   So, what's stopping a haxor like me from strobbing a gateway with random

  Ok, so lets think about how that's going to work.  It's well defined how you
encrypt and authenticate your SIP messages, no big deal.  But what about media?

  SDP provides a k= line to convey an encryption key, but it does not describe
how to practically make use of it.

  I admit I'm not up to speed on this, but is there a draft on how to
interoperably initiate an encrypted audio stream using G.711 encoding?  Is the
vagueness of draft-ietf-avt-profile-new-08.txt what I should be going on?

  Regardless, if I find the IP address of a SIP-PSTN gateway, it's bound to
also support unencrypted connections.  Sending audio probes at it seems to be a
completely reasonable tactic as far as I'm concerned.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Feb 2000 16:06:46 -0500

> how to practically make use of it.

True enough. The original idea is that the SIP INVITE would be
encrypted, and the body contains the key for the media session. The key
is used for RTP level encryption. No particular algorithm is specified
for SIP, a hole we are working to plug.

As an alternative, one can set up an ipsec association for the media.
This just requires the SDP to somehow indicate that ipsec is desired;
the rest is up to ike, ipsec and its related friends. This is described
in:

http://www.normos.org/ietf/draft/draft-ietf-mmusic-sdp-qos-00.txt

although the ipsec/ike stuff is not described, just the SIP/SDP
component.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Dean Willis <[email-masked]>
Date: Tue, 08 Feb 2000 15:26:49 -0600

>   So, what's stopping a haxor like me from strobbing a gateway with random

This came up in the SIP security design team.

We have some hope that the receiver can pay attention to the SSRC and
discard your spam. Of course, if you can guess the SSRC, you can get in.

I once pointed out that one solution would be to extend SDP to include the
source address. Of course, this could always be spoofed.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Feb 2000 16:40:46 -0500

> Andrew Chalupka wrote:
> 
> Assume a user, "caller", initiates a SIP call with a second user,
> "callee", through the usual means (INVITE, 200 OK, ACK).  During this
> message exchange, each end speficies the IP address and UDP port
> number(s) to which the other end should send his audio stream.  Would
> it be a violation of the SIP standard for one of the participants to
> send his audio stream to a third party (say to a server which might
> transcode the sender's audio packets into a format the other end can
> understand) and then have that third party forward the packets on to
> the appropriate destination?

No, its not a violation at all. If security is being used for the media
streams, there are key distribution issues, but there is nothing that
stops you from doing this. In fact, sending media to a different IP
address than the one which terminates the SIP is needed for MGCP/megaco
- perhaps that is what you are talking about.

-Jonathan R.

---

From: Billy Biggs <[email-masked]>
Date: Tue, 8 Feb 2000 15:42:05 -0600

> discard your spam. Of course, if you can guess the SSRC, you can get in.

  Well, I don't think you can count on the SSRC being constant throughout the
call.  Why can't I stop sending audio from one source and begin sending it from
another with a different SSRC?  It wouldn't violate the context of the SIP call
if I'm still receiving media at the address I specified in my SDP.

> source address. Of course, this could always be spoofed.

  Which SDP?  Would my sipcaster, which just sends media, have to send SDP just
to indicate where media would come from?  A field like that wouldn't make sense
in the context of SDP.

  It also wouldn't make sense in the context of SIP though, since SIP isn't
meant to discuss the media at all.

  So, you're kinda screwed there too...  There really isn't any place that you
should put it...  The only solution is crypto, which at this point seems too
undefined for practical use.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Feb 2000 17:09:19 -0500

Billy Biggs wrote:

> undefined for practical use.

RTP crypto is sufficiently defined to have been interworking since the
early 90's, as long as you stick to encrypting the whole RTP packet
using DES or 3DES, not just the payload. Indeed, vat, rat and nevot have
used encryption for at least five years. (Just encrypting the payload is
useless for preventing attacks since one can't tell whether the
decryption transformation yielded a valid packet or not, at least for
codecs whose bit streams are not heavily structured. This includes G.711
and probably most other audio codecs.)

RTP-level encryption has the advantage that it doesn't inflate the
packet size and doesn't require OS support.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Tue, 8 Feb 2000 17:17:37 -0600

> and probably most other audio codecs.)

  So, are you suggesting that for building a SIP client that receives encrypted
media it should attempt to decrypt every incomming packet and see if it
'works'?  I guess this should be only attempted if an encryption key is
specified inside the SDP, or if the user explicitly sets a shared secret key...

  Assuming that the k= line will be encrypted inside a secure SIP message, we
still need to specify at some point the algorithm to be used for the
encryption.  As far as I can tell, this is unspecified.  So, again, should a
client keep trying supported algorithms until it 'works'?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Feb 2000 18:28:10 -0500

Billy Biggs wrote:

> specified inside the SDP, or if the user explicitly sets a shared secret key...

Indeed, this assumes that the key is known to the other side.

RFC 1890 describes how the key and algorithm are encoded, with the name
space given in RFC 1423. This string is then included in SDP.

> client keep trying supported algorithms until it 'works'?

No. Please reread RFC 1890.

---

From: Jonathan Lundell <[email-masked]>
Date: Tue, 8 Feb 2000 21:15:36 -0800

> >   So, what's stopping a haxor like me from strobbing a gateway with random

I'm ignorant of the capabilities of the specific relevant protocols here, but isn't (simpler and cheaper) authentication, rather than encryption, called for here?

/Jonathan Lundell.

---

From: Dean Willis <[email-masked]>
Date: Tue, 08 Feb 2000 23:42:06 -0600

> to indicate where media would come from?  A field like that

Actually, I would propose the answer to that question should be "yes". And
if the source changes, a reinvite is needed to change the describing SDP.

Here's why -- lots of people are trying to build dynamic firewall rules.
They'd like to be able to inspect (not interact with) the SIP packets going
past and be able to deduce the minimal access lists that would allow the
associated RTP/UDP streams to pass. With the current usage, we have only
three elements of the 5-tuple (source address, source port, destination
address, destination port, protocol) that describes each flow (one 5-tuple
for each direction or media half-leg). We have protocol, destination
address, and destination port number. One really needs at least the source
IP address to make a reasonable ACL entry, and that doesn't protect calls
originating from multisuer machines from being jammed by other users on that
machine. Ideally, we should have the whole 5-tuple, or multiple 5-tuples
that describe additional peerings such as might be experienced from a
multihomed host that load balances its transmitting interfaces.

So, how do the firewall people work around it? They start making
assumptions, such as that each endpoint will send and receive media from the
same IP address. This is potentially a very bad assumption, but it appears
to be likely to be the state-of-the-art in SIP-aware packet filtering
firewalls for some time. I'd rather give the the data to do the job closer
to right.

The good news is that even at its worst, SIP is still easier to deal with in
the firewall than is H.323.

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 09 Feb 2000 09:53:50 +0200

Hi, 

I guess the question in the first mail of this thread was something
like:

A sends an INVITE to B, and B answers with a 200 OK. There is no codec
that both can support. A transcoding unit is necessary.

1) A proxy server can monitor the SDPs of both parties, and modify them
in order the media stream to go though the transcoding point. For doing
that, the proxy should be able to understand the SDP (decrypt it).
Firewalls work like this. See example "Successful SIP to SIP through SIP
Firewall Proxy" in page 34 of
http://www.cs.columbia.edu/sip/drafts/draft-johnston-sip-call-flows-00.txt

2) A could INVITE the trasnscoding point (SIP capable) using an "also"
header for B. This way the user is in control and knows that transcoding
is being peformed.

About encrypting RTP streams:
Henning wrote the following when
http://www.cs.columbia.edu/sip/drafts/draft-nair-sip-dhcp-00.txt was
released:
"A particular concern of
ours are low-complexity embedded systems (such as
http://www.cs.columbia.edu/~hgs/ephone) that may not support DNS and do
not have the computational resources to host an SLP implementation."
Probably low-processing power devices will not be able to cope with RTP
encryption/decryption in real time.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Lars Berggren <[email-masked]>
Date: Wed, 9 Feb 2000 14:00:55 +0100 (CET)

> for SIP, a hole we are working to plug.

If the SIP INVITE is encrypted using the callee's public key things will
not work when traversing a firewall proxy or any other SIP-hop that needs
to change the SDP addresses in order to proxy media streams.

To support RTP level encryption through a firewall proxy (FW), is the
caller supposed to encrypt the SIP INVITE using the FW's public key so
that the FW can decrypt, change SDP, and encrypt again using the callee's
public key? It doesn't seem realistic to do this amount of processing in
the FW, I think.

I'm not sure how RTP works, but assuming the FW does not need to
inspect/change RTP packets going through it in order for RTP-things to
work, RTP level encryption through firewalls can be supported if the
encryption key can be transferred encrypted without having to encrypt the
whole SDP. I think some kind of mechanism for transferring the 
RTP-encryption-key encrypted without having the whole SDP encrypted would
be useful.

The kind of mechanisms I can come up with are:
1) The value of k= in SDP is encrypted using the recipients public key.
2) A SIP-header for transferring the RTP-key encrypted.
3) An additional body with the RTP-key encrypted.
4) Some kind of change to the SIP-end-to-end-encryption mechanism can
solve the problems of encryption through firewalls in a more general way.
5) Extra SIP re-INVITE round-trip with SDP k= only.
6) Using k=uri or k=prompt to obtain the key. This is already specified in
SDP.

Or will ipsec behave well through firewalls?

Comments?

/Lars.

> although the ipsec/ike stuff is not described, just the SIP/SDP

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Feb 2000 08:47:54 -0500

> to change the SDP addresses in order to proxy media streams.

Thats correct. 

> public key? It doesn't seem realistic to do this amount of processing in

No. How would the caller know it needs to do this? Rather, I believe the
right solution is one of the following:

1. Don't encrypt the SDP. Use some new paramters in an SDP extension to
do a diffie helman exchange to arrive at a shared session key. Then, use
RTP encryption for the media. Benefits: still works through firewalls,
no ipsec overheads. Drawbacks: yet another SDP extension, may introduce
security holes by doing diffie helman ourselves.

2. Don't encrypt SDP or use it for key exchange. Based on
http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sdp-qos-00.txt,
make security an optional precondition for call setup. This will result
in ike/ipsec stuff to exchange keys and set up an ipsec connection for
the media. Benefits: also works through firewalls, uses standard ipsec
stuff. Drawbacks: ipsec, especially tunnel mode, adds a lot of overhead
to already small RTP packets.

> Or will ipsec behave well through firewalls?

Firewalls can be traversed. NATs are not a good story. NATs rewrite
headers which are protected by ipsec.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 09:19:51 -0500

Jonathan Rosenberg wrote:

> to already small RTP packets.

A third solution which is far simpler: Don't encrypt inside the firewall
- we don't do this for other internal traffic anyway. The FW (more
precisely, the outbound proxy) encrypts the SIP message using the
recipient's public key, after modifying the SDP IP address
appropriately. This even allows the FW to insist on media encryption
between it and the outside world, even if the inside device is not
encryption-capable (as might be the case for embedded devices, although
DES support is far simpler than a complete SLP implementation, in terms
of code-space...). Having simple end systems implement IKE is, in my
view, pretty hopeless, given its complexity.

DH is subject to man-in-the-middle attacks, unless the parties have a
public number that the other party can look up securely. Not that
different from a public key in that case.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Feb 2000 08:06:05 -0800 (PST)

The packetcable security spec specifies a 2 or 4
byte MAC (using MMH) to be appended to the RTP
packet itself. I have argued that RFC 2198 might
actually be a cleaner way to append the MAC
itself, but so long as the parties agree to the
payload format, a relatively weak MAC should make
barge in sufficiently difficult that even if an
attacker managed to get through every once in a
while, they probably wouldn't do anything
especially exciting.

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 11:23:10 -0500

> byte MAC (using MMH) to be appended to the RTP

Is this simply hash(RTP packet | shared secret)?

Could the bad guy record a conversation, including the hash, and then
mix in the old data with the "real" one?

> while, they probably wouldn't do anything

Since this is an RTP issue, I wonder if this shouldn't be written up for
avt. Another possibility is an RTP header extension. That, at least,
would be backward compatible with non-MMH implementations.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 09 Feb 2000 18:03:27 +0000

--> Henning Schulzrinne writes:
>Michael Thomas wrote:
>> I do sort of like the idea of the MAC being a
>> payload not entirely unlike a codec payload,
>> though I'm not wedded to the notion. It does have
>> the advantage that we can offer up the MAC "codec"
>> up in SDP m= as being something that the endpoint
>> is willing to receive. With RFC 2198, the sender
>> would then oblige by sending several different
>> "codecs", namely the real codec and the MAC at the
>> same time.
>
>My major concern with this is that there's a fair amount of overhead
>just to get 2 or 4 bytes across.

It's one more byte than using the RTP header extension.....

Still, it may be better to define a new RTP profile which includes the 
MAC as part of the fixed RTP header. That's probably the solution with 
the least overhead, and the protocol definition can be straightforward
RFC1890 + 4 bytes of MAC header.

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 12:27:20 -0500

Michael Thomas wrote:

> Whatever way has the least number of bytes is
> probably the right answer. Packetcable's only
> incurs the cost of the MAC itself since there is
> an agreement between the sender and receiver that
> there be the MAC tacked on to the end. Since it's
> a trailer, it ought not effect a naive
> implementation (though it would certainly violate
> the "conservative in what you send" principle).

Since RTP doesn't have a length field, a "naive" implementation would
treat the MAC bytes as G.711 samples. Not good.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Feb 2000 11:00:01 -0800 (PST)

> RFC1890 + 4 bytes of MAC header.

Would that not lead to a combinatorial explosion
of name space with rtpmap in SDP? Ie, G711-MMH2,
etc?  I'm all for having zero overhead, but not at
the expense of making a mess of SDP. That is sort
of why I was attracted to RFC 2198. If somebody
else has a better way of doing the same thing
without requiring, for example, structured names
in SDP that would be great too.
  
	Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Feb 2000 09:06:19 -0800 (PST)

> Is this simply hash(RTP packet | shared secret)?

Yes. In packetcable, the payload is encrypted with
RC4, but the MAC is applied to the entire RTP
packet.
 
 > mix in the old data with the "real" one?

Not if you use the RTP timestamp. Built in
replay protection :-)

	       Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 14:15:30 -0500

Michael Thomas wrote:

> of name space with rtpmap in SDP? Ie, G711-MMH2,

No, not really, this designation would replace the RTP/AVP in SDP with
something like RTP/AVP-MMH. The codec names would stay the same, since
they are unaffected by this change. .

---

From: "'Billy Biggs'" <[email-masked]>
Date: Wed, 9 Feb 2000 15:13:47 -0600

Robert Sparks ([email-masked]):

> Billy - I agree with Dean that you should issue a new INVITE when you change
> your source port/address. This only makes sense of course, if the INVITE
> contains information about that source port/address. You claim such
> information doesn't make sense in the context of SDP. Why not? I can see (yet
> another) simple field addition to cover that for unicast sessions. I'm not
> proposing that right now btw - but I do strongly believe that we need to make
> the media source part of session negotiaton. This should be addressed now, in
> parallel with the important encryption discussion.

  My understanding of SIP's use of SDP is that it is used strictly as an
announcement of what you are willing to receive.  To indicate any other
information would be premature, since one can't speak objectively about the
call in full until all signalling has been completed.

  I personally think it's important that SDP not be used as a negotiation
protocol, since that would be well beyond the scope of the protocol.

  SIP definitely allows changing the media source address without updating
either of the session descriptions, since they each only discuss the receiving
end of the conversation.  Therefore, the media source can change mid-call
without an INVITE.  This seems completely valid, and even 'clean'.

  Regardless, the purpose of indicating the source address of where media is
invalidated by the simplicity of spoofing RTP.

> Billy Biggs ([email-masked]) :
> > > I once pointed out that one solution would be to extend SDP to include
> > > the source address. Of course, this could always be spoofed.
> > 
> >   Which SDP?  Would my sipcaster, which just sends media, have to send SDP
> > just to indicate where media would come from?  A field like that wouldn't
> > make sense in the context of SDP.
> > 
> >   So, you're kinda screwed there too...  There really isn't any place that
> > you should put it...  The only solution is crypto, which at this point
> > seems too undefined for practical use.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 09 Feb 2000 13:36:19 -0600

The SSRC may change even when the source does not. An RTP
implementation is required to be prepared to do so in the
case of SSRC collision detection. IIRC, there's nothing
in the RTP spec to prevent an implementation from whimsically
changing to a new SSRC at any time.

Billy - I agree with Dean that you should issue a new INVITE when
you change your source port/address. This only makes sense
of course, if the INVITE contains information about that source
port/address. You claim such information doesn't make sense
in the context of SDP. Why not? I can see (yet another) simple field
addition to cover that for unicast sessions. I'm not proposing that
right now btw - but I do strongly believe that we need to make the
media source part of session negotiaton. This should be addressed
now, in parallel with the important encryption discussion.

RjS

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of 
> Billy Biggs
> Sent: Tuesday, February 08, 2000 3:42 PM
> To: Dean Willis
> Cc: Andrew Chalupka; 'SIP List'
> Subject: Re: Question about media desinations
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Feb 2000 19:18:08 -0500

> now, in parallel with the important encryption discussion.

I'm not clear on whether the source port and address are really needed.
I thought that firewalls allowed rules without exact values for the
5-tuples. Certainly you'll need that for other applications - for
example, getting http out through a firewall via an internal proxy. In
that case, your rule only specifies a destination port and source IP
address.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 10 Feb 2000 02:18:20 +0100

> that case, your rule only specifies a destination port and source IP

Jonathan,

it is not a matter of what the firewall allows you to do but what you
want them to do.

(Most state-of-the-art routers support arbitrary filtering policies. The
filtering rules may be based on any subset of src/dst port/address,
protocol and even more. I guess that you can even parse deeper and
for example, investigate RTP sequence numbers. Of course, the processing
overhead grows with number of filtering rules and number of investigated
header fields.)

Dean's motivation behind indicating sender's port numbers in SIP/SDP
(sorry if I misunderstood) is the most restrictive filtering policy 
'default-deny-explicit-permit', where the explicit permissions are 
dynamically controlled by a SIP/SDP-aware entity and describe an
authorized 
IP stream by the 5-tuples. (BTW, could anyone point out a study on how
the processing overhead scales with the number of rules?)

If the source port number and address of the session flows
entering the firewall from the Internet are unknown to the SIP/SDP
entity, they cannot be included in the filtering rule and then
the firewall allows packets with any source addresses/ports
(i.e. even those that do not belong to the session) to reach the 
receiver.

This can be fixed by including source address/port in SIP/SDP, although
as Billy pointed out, packets with spoofed src address/port may still
fool the firewall.

Jiri

-- 
Jiri Kuthan		  Phone: ++49 / (0)30 / 3463 - 7 271
GMD FOKUS                 Fax  : ++49 / (0)30 / 3463 - 8 271
Kaiserin-Augusta-Allee 31 E-Mail : [email-masked]
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Feb 2000 09:56:41 -0500

> as Billy pointed out, packets with spoofed src address/port may still

I see.

Another difficulty with sending the source IP address in SDP is that we
break one of the very  nice features of RTP, the independence of user
association from IP address. 

I recognize the desire for increased security (especially in light of
the recent attacks
against ebay, yahoo, etc.), but I am wondering if adding this to SDP
really buys you
much. Without this, an attacker must still guess the destination IP
address for media and
the destination port and a time during which a call is active. Adding
the source means it must also guess that. Is it enough extra?

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 10 Feb 2000 20:51:49 +0100

> the source means it must also guess that. Is it enough extra?

In general, packet filtering reduces the security risks. The more
precise
the rules the lower the risk. However, even if very precise rules are
deployed, spoofing cannot be prevented unless a kind of packet 
authorization based on a cryptographic method is used. For example, 
a MAC covering the relevant header fields would have to be included 
in every packet. The MAC secret key could be signaled with SIP.

The questions I see are:
1) Does the benefit of more precise rules justify including the source
   address/port in SDP? (rewording of what Jonathan asked)
2) Does the packet authorization make sense? Can its computational
   and bandwidth overhead be kept low? Can be some existing
   work reused? Are we going to focus on this problem?

Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Feb 2000 16:09:54 -0500

>    work reused? Are we going to focus on this problem?

Using a MAC solves a different problem. The firewall stops the attack
that has recently been launched - just flooding the host with packets.
These packets may fail authentication, but their mere presence may cause
the host to be overloaded just verifying and discarding them.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Thu, 10 Feb 2000 23:13:11 -0600

> the source means it must also guess that. Is it enough extra?

Without source-address rules in the firewall, an attacker can simply scan
for addresses that don't return an "ICMP administratively denied", then scan
each such address for ports that don't return "ICMP port unreachable". If
the port isn't one normally used for something else, chances are its a media
port and can be spammed with an RTP stream. This is pretty easy.

With source-address rules in the firewall, the intruder most know enough to
launch a scan with spoofed source addresses from a host likely to be in
session with a host behind the firewall, and must be able to contrive to
receive return packets to the spoofed address to detect success. This is
fairly hard.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Feb 2000 11:37:42 -0500

> port and can be spammed with an RTP stream. This is pretty easy.

This presumes a firewall sends an ICMP error message when it discards
the packet. I would
think they would blackhole them, which will eliminate the ability to
conduct this attack
you describe.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Feb 2000 00:15:45 -0600

Try scanning the net at 63.81.221.0/24, for example by telneting to port 122
on 63.81.221.234 -- you'll get back lots of "packet filtered" messages. The
default behavior in most systems is to return such a message. Some firewall
implementors turn them off. Most don't.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Feb 2000 12:11:18 -0500

This raises an important point. I don't want to make changes to SDP and
its usage within SIP to fix a problem that can be prevented by an
administrative change in firewall behavior. If the firewalls did not
return these error messages, do you still believe including the source
port and address in the SDP is useful? 

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Feb 2000 12:22:19 -0500

Generally speaking, unless there's a strong reason not to, CS comparison
is far preferable, since with UTF-8, doing CI comparison is non-trivial.
In full fledged OS environments, somebody probably has already taken
care of all the hassle of deciding what the upper case equivalents of
different characters are, but in an embedded environment, most people
are going to deal correctly with ASCII, if we're lucky. Thus, to avoid
I18N surprises later, byte-by-byte comparison (i.e, CS) seems generally
preferable unless we are forced by convention, e.g., for hostnames
(where currently non-ASCII letters are less of an issue) and for header
names (where non-ASCII choices for standardized headers are not likely).
CS comparison is also somewhat slower.

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Feb 2000 18:51:17 -0600

Yes. Having both endpoints allows the firewall to construct a far more
effective dynamic ACL. It also allows UAs to selectively bind their RTP
streams to a specific partner, rather than waiting open-eared for a download
of spam.

--
Dean

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 11:11 AM
> To: Dean Willis
> Cc: 'SIP List'

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 14:09:45 -0500

Hmmm. Actually, placing the source address in the SDP solves another
problem. When multiple 200 OK (or 183 or whatever) arrive with SDP, the
caller is going to receive audio all on the same port, with no way to
figure out which RTP stream corresponds to which call leg. By adding the
source address, the UAC will be able to correlate them.

I guess the next step is to write up the SDP extension as a small draft
and submit it to mmusic, as its really an mmusic issue and not a sip
one.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2000 15:48:41 -0500

> source address, the UAC will be able to correlate them.

While this is helpful, it is not foolproof, since RTP translators will
mess up the IP address. I think RTCP-based means are preferable. Also,
for multi-homed hosts, it's not always easy to know at the application
layer, which source address is going to be used, since that can depend
on routing. While this is probably infrequent, relying on it may be
suboptimal. Maybe RTCP SDES should contain the appropriate identifier,
including tag.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 17 Feb 2000 15:35:04 -0600

How would an RTP translator get into the media path of a
SIP initiated session without one of the SIP participants
being aware of it during the setup?

Multi-homed SIP entities already have to discover which
interfaces are going to participate in a given SIP 
transaction (for proper construction of Vias, Contacts,
Record-Routes, and possibly the receiving address in
session description).

In the context of an RTCP-based solution and the case that
Jonathan describes, what would the client do with RTP
packets received before the first associated RTCP packet
arrives?

RjS

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2000 17:12:31 -0500

> being aware of it during the setup?

Never mind...

> Record-Routes, and possibly the receiving address in

Not really, since if the receiver binds on INADDR_ANY, it doesn't matter
which interface the SIP packet comes in on.

> packets received before the first associated RTCP packet

Mix it and play it out. Streams can be distinguished based on SSRC, they
just can't be identified with some blinking icon which says "Joe is
talking right now".

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 18:16:27 -0500

[email-masked] wrote:
> 
> Jonathan Rosenberg writes:
> The easy way to figure out which RTP stream corresponds to which SIP
> call is to use different destination port numbers. I don't think
> you can always distinguish calls based on source address, I don't
> think there's anything in the RTP spec which says I can't send two
> different RTP streams from the same port.

Clearly thats the preferred solution, but it doesn't work for multiple
200 OK - thats my point. The INVITE contains the port I expect to
receive media on. If two gateways receive that, and each send a 183 and
then send media, they will end up sending media to that same port. Thus,
I cannot use the port to differentiate. Of course, I will realize there
are two separate streams. These two streams will generally have
different SSRC, so I can separate them. However, there is no way to
correlate a particular stream (identified by its SSRC) with the SIP call
leg.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2000 09:56:58 -0500

> just can't be identified with some blinking icon which says "Joe is

The bigger problem is firewalls. If we presume that the firewall won't
let things through unless it has the source address at least (source
port as well I guess would be desirable), the RTCP will never get
through in the first place. 

I'm not 100% convinced of putting the source address/port in the SDP yet
- still trying to understand the pros and cons.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Feb 2000 08:57:03 -0600

> which interface the SIP packet comes in on.

If the interfaces are to discrete networks, there could be
no valid response path to a request with a Via indicating
the wrong interface.

RjS

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Feb 2000 10:11:18 -0500

> - still trying to understand the pros and cons.

I wonder how firewalls handle current RealAudio streams. I gather that
most do allow Real UDP packets through, although I haven't checked this.

---

From: [email-masked]
Date: Thu, 17 Feb 2000 22:00:31 +0100 (MET)

It seems like we have a few choices:

1. Distinguish streams based on destination port #. This might make
   life harder for firewalls and firewall administrators; it's easiest
   to just open port 5004 for RTP.

2. Distinguish streams based on SSRC. This is a bad idea; you can't
   be sure that a client won't change SSRC from packet to packet.
   You also can't be sure that two clients talkign to a gateway
   won't choose the same SSRC, however unlikely that may be in theory.

3. Distinguish streams based on source address and port. (as above)

The first option seems qutie clearly the least of three evils.

Matthias