Subject: Re: [Sip] submission of a new I-D: "Dialog Event foR IdentityVErification"

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 13:46:25 +0100

El Viernes, 31 de Octubre de 2008, Victor Pascual Ávila escribió:
> Hi Iñaki,
>
> On Fri, Oct 31, 2008 at 2:03 PM, Iñaki Baz Castillo <[email-masked]> wrote:
> > 2008/10/31 Michael Procter <[email-masked]>:
> >>> Shall DERIVE be extended to support non-INVITE requests (e.g. MESSAGE)
> >>
> >> I'm not sure it can.  RFC4235 is defined for INVITE-initiated dialog
> >> usages only.  Yes, it could be extended, but I'm not convinced that is
> >> necessarily the best way forward from here!
> >
> > Also note that MESSAGE doesn't establish a dialog, it just an
> > independent transaction.
>
> Do you mean that we should provide a reasonable assurance that the
> "Caller-ID" is not misleading ONLY for dialog-forming requests?

Well, the problem is that DERIVE wouldn't work for non INVITE dialogs since 
RFC 4235 just involve INVITE dialogs.
DERIVE is a good proposal since it reuses existing (and *really* implemented) 
features (as Dialog Event Package), but verifying Caller-ID in non INVITE 
requests must be subject of a new and independent proposal.

IMHO, the best behaviour would be something as Juha's proposal (not sure if 
it's something as follows):

   bob                          alice
       F1 MESSAGE -------------->
       <----------------- F2 INFO
       200 (INFO) -------------->
       <------------ 200 (MESSAGE)

- F1:
MESSAGE sip:[email-masked] SIP/2.0
From: <sip:[email-masked]>;tag=1234
Call-ID: abcd

- F2:
INFO sip:[email-masked] SIP/2.0
Require: callerid-verify
CallerID-Verify: call-id=abcd;from-tag=1234
Content-Length: 0

bob would reply "481 Call/Transaction doesn't exist" if it's not a request 
from him, a "200 OK" if it's, "420 Bad Extension" if it doesn't support this 
feature, and any other 4XX if bob (or a proxy in the middle) can't answer it 
(so the response is undefined).

This would work with INVITE, MESSAGE and any kind of request, but it wouldn't 
work inmediately with devices already supporting RFC4235, so we'd have again 
a exotic specification with no real implementation.

-- 
Iñaki Baz Castillo
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 13:57:55 +0100

El Viernes, 31 de Octubre de 2008, Dean Willis escribió:

> Now, from a security perspective: Who's done the analysis on whether
> DERIVE introduces new attack opportunities?
>
> For example, is there a DOS opportunity in using the home proxy as a
> message-exploder for source-forged SUBSCRIBE requests? Seems like thre
> might be a problem there . . .

Do you mean something as:

  attacker              alice                 bob (victim)
  INVITE (From: bob) ----->
                        SUBSCRIBE ------------->
  INVITE (From: bob) ----->
                        SUBSCRIBE ------------->
  INVITE (From: bob) ----->
                        SUBSCRIBE ------------->
  INVITE (From: bob) ----->
                        SUBSCRIBE ------------->

?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 14:05:10 +0100

El Viernes, 31 de Octubre de 2008, Adam Roach escribió:
> And, in any case, you can't send an INFO out of dialog. So you can't
> route it to the address in the From

Where is specified that INFO can't be sent out of a dialog as initial request?
Well, RFC 2976 (INFO) just defines INFO as an in-dialog request, but why 
couldn't a new document make use of INFO out of dialog?

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Nov 2008 10:41:49 -0400

See RFC 5057.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 16:48:45 +0100

> See RFC 5057.

I promise I'll read it entirely, but in a fast read I don't find what you 
could suggest, just considerations about dialog forming.
Could you please point to me what exactly you mean? Perhaps that INFO 
shouldn't be used as an initial request?

Thanks a lot.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Nov 2008 12:14:09 -0400

The original draft for INFO (like most from that time) were pretty 
loosely worded. That is part of the trouble. So its been necessary to 
interpret intent.

It seems clear that the original definition was intended to convey 
information that was closely tied to the session. Without a session that 
doesn't make sense.

The current effort to clarify this (the info package work submitted by 
Eric Burger, and subject to vigorous debate recently) will certainly 
nail it down further. That is proposing to *negotiate* the packages to 
be delivered, and the negotiation takes place within the invite dialog 
usage. (Much like offer/answer.) This ties INFO more closely to the session.

If you have an application for INFO outside of the invite dialog usage, 
then you could submit a draft proposing that. I wouldn't recommend doing 
so. It wouldn't be well received.

	Thanks,
	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 1 Nov 2008 18:20:26 +0200

> so. It wouldn't be well received.

if SUBSCRIBE is not used for this, then OPTIONS might be a possibility.

-- juha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 1 Nov 2008 17:31:09 +0100

> so. It wouldn't be well received.

Thanks for clarification.

In this case, any other request method could be used (OPTIONS, MESSAGE...).

---

From: Dean Willis <[email-masked]>
Date: Sat, 1 Nov 2008 16:23:47 -0500

>  INVITE (From: bob) ----->

Yeah.

And factoring in retransmission requests . . .

Alice is the target of the attack.

Evil Dave forges an INVITE with DERIVE-supported from Alice to Bob.

Bob then sends a SUBSCRIBE to Alice. Alice either 404s, or (if she  
doesn't support  4235) does something like ignore the request. Bob  
then retransmits through the NIT-retransmission cycle, thereby  
generating a factor-N attack multiplication with indirection.

Now, if Dave really hates Alice, Dave sends the same sort of forged  
INVITE to Carol and Eugene and Frank and everbody else.

Alice is the one being attacked, but she can't trace the source of the  
attack back to Dave's I P address without cooperation from Bob and the  
other relayers.

Is this any worse than the multiplier already built into SIP? It's  
probably not any worse than the "voice hammer" attack, although it's  
different in that it floods the signaling channel, not the media  
channel. So really, it's Alice's proxy that is the target of such an  
attack.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 1 Nov 2008 16:26:29 -0500

> couldn't a new document make use of INFO out of dialog?

Ooh, that's a big can of worms to open.

It strikes me that DERIVE is in many ways similar to the non-deployed  
SIP Consent Framework. Think about it.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 1 Nov 2008 16:29:31 -0500

On Nov 1, 2008, at 11:14 AM, Paul Kyzivat wrote:

> loosely worded. That is part of the trouble. So its been necessary  
> to interpret intent.
>
> information that was closely tied to the session. Without a session  
> that doesn't make sense.
>

I would argue that when Steve, Matt and I invented it on the  
whiteboard at MCI, we were thinking about using INFO for out-of-dialog  
instant messages. We were also thinking of using it in-dialog for  
presence updates (using an INVITE-formed dialog).

But it mutated after it hit paper and the MMUSIC working group's  
review cycle.

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 03 Nov 2008 17:00:46 +0100

> In this case, any other request method could be used (OPTIONS, MESSAGE...).

In fact, if we were not to reuse dialog package, I would prefer a separate
method rather than overloading an existing one. The beauty of the dialog
package is it comes for free, the downside is it is indeed limited to
the dialogs. The problem to me is both appear appealing in their own way :)

-jiri