Subject: RE: Proxy Server Inconsistencies

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Thu, 28 Jan 1999 21:09:27 -0000

Well, at least we are down from three to two options.

One point on the re-Invite method is that clients would be required to also
refresh the session timer, even if there was no stateful proxy involved in
the session signaling.  The PING method would only be used when a stateful
proxy was involved.

One method to avoid the malicious proxy is to allow the Pinging proxy to
PING in both directions.  It is unlikely that a malicious proxy would exist
in both directions.

Any suggestions on how we should pursue selecting one option over the other?

Steve

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Thursday, January 28, 1999 9:43 AM
> To:	Adam B. Roach
> Cc:	[email-masked]; Willis, Dean.; [email-masked]
> Subject:	Re: Proxy Server Inconsistencies
> 
> Adam B. Roach wrote:
> > 
> > >I think its possibly a subtle security problem. In the above case, the
> > >UAS is not involved. It is P2 which initiates the query. Lets say P1
> > >lies, and tells P2 the call is no longer active. Neither the UAS nor
> the
> > >UAC ever see this, and so presumably they know that the call is still
> > >active, and there is no effect for them. The only one that suffers is
> > >P2.
> > 
> > I can't argue with that.
> > 
> > I can, however, ask why on earth anyone would ever program a
> > proxy to produce such bizarre and useless behavior. Is there some
> > potential gain to be realised? Is there any real harm to be incurred,
> > except interrupting the services provided by P2?
> 
> Interrupting the services provided by P2 is exactly the goal. If P1 and
> P2 are competitors, doing this to P2 without interrupting the call is a
> denial of service attack.
> 
> > Wouldn't users start avoiding that proxy and trying to find
> alternatives,
> > once they realised it was programmed by a lunatic?
> 
> Well, probably not a LUNATIC, but someone who is intent on being
> malicious. The users might seek alternatives later, depending on whether
> they notice and what the nature of the affected services are.
> 
> > 
> > >Now, consider the case where the UAC initiates the keepalive, by
> sending
> > >keepalives through the chain to the UAS, and expecting a response. P1
> > >can still "lie" by refusing to forward the keepalive. But, when it does
> > >this, the UAC and UAS will believe that the call has terminated, and
> > >hangup. This is bad for P1 too, so there is no real incentive to do
> > >this. In the previous case, nothing bad happens to P1.
> > 
> > Ah. But if we're being *this* paranoid, what if P1 examines the
> > "Route:" headers, and skips P2, instead sending the keep-alive
> > directly to P3?
> 
> An excellent point. Yes, this would appear to enable the same DOS attack
> in the end to end keepalive.
> 
> Perhaps as an academic exercise, there seems to be a way to detect the
> abuses of P1 in this scenario. When the UAC sends the request, it would
> encrypt the request with the UAS public key, then encrypt that with P2's
> public key, then encrypt that with P1's public key, and then send the
> thing to P1. Each proxy decrypts and sends downstream. This insures that
> unless the request takes the path specified by the UAC, the message is
> unreadable by the UAS. So, having P1 misroute the request would be just
> the same as dropping it. 
> 
> Now, I'm not proposing that we do this, its just a thought.
> 
> So, it seems there are two possibilities that I believe make sense:
> 
> 1. an end to end keepalive (done as a re-INVITE), with an additional
> header which specifies the keepalive frequency
> 
> 2. a new method, PING (or perhaps an extension to OPTIONS) sent by the
> proxies to both UAS and UAC; perhaps with some kind of caching of
> liveness at intermediate proxies.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: [email-masked]
> URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Jan 1999 17:47:44 -0500

> "Donovan, Steven R. (MCI)" wrote:
> 
> One point on the re-Invite method is that clients would be required to
> also refresh the session timer, even if there was no stateful proxy
> involved in the session signaling.  The PING method would only be used
> when a stateful proxy was involved.
> 
> One method to avoid the malicious proxy is to allow the Pinging proxy
> to PING in both directions.  It is unlikely that a malicious proxy
> would exist in both directions.
> 

If it turns out that time-limited sessions are useful, then the session
time limit allows to support that without additional mechanism. Thus, I
would guess that we should have session time limits, even if turns out
that an "active" mechanism is useful. Session time limits might be
useful for all kinds of prepaid-{calling/game-playing/subscription}-type
applications, but I'm curious if there are other possible applications
beyond this and liveness detection.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs