Subject: RE: Proxy Server Inconsistencies

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

It seems like there are three options for a SIP extension draft that would
address the problem of a stateful proxy being able to determine whether or
not sessions are still active.

1) Add a user agent based session keep alive message (I'm still involved in
this session).  The proxy would tear down the session if the keep alive was
not received within a predefined timer.  

2) Add a proxy based session ping message (Are you still involved in this
session).  The proxy would wait for a response to the ping request.  If no
response is received within a predefined time then the proxy would tear down
the session.

3) Adding a session expires parameter to the Invite.  The expires time could
be updated with a subsequent invite for the session.  The proxy would have
the ability to tear down the session when the session time has expired.
This would presumably be achieved by the proxy sending a BYE to both parties
involved in the call.  There may be the need for a maximum session expires
duration to prevent a user agent from specifying the year 2100 as the
expires time of a session.

All three approaches add to the complexity of the user agent and proxy,
however only marginally.

The third approach seems to minimize the amount of messaging required.

Based on those two criteria, the third option seems preferable.  Are there
other options and criteria that should be factored into the analysis?

Steve

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Wednesday, January 20, 1999 2:27 PM
> To:	Henning Schulzrinne
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	Re: Proxy Server Inconsistancies
> 
> Henning Schulzrinne wrote:
> > 
> 
> > > I understand the point that a SIP keep alive would typically be
> redundant
> > > with media exchange, but I don't believe this is universally true.
> E.g.,
> > > suppose I want to monitor a sleeping infant, and I use a media
> encoding
> > > that doesn't transmit anything during periods of inactivity.  I can
> imagine
> > > other "shared presence" applications, where little media is exchanged,
> the
> > > point is in the potential.  I don't believe a media transport agent
> has any
> > > intrinsic "keep alive" responsibilities; it simply must insure that
> WHEN it
> > > is transmitting data, there is someone to receive it.  What needs to
> be
> > > "kept alive" (or, actually, allowed to time-out) is the "in
> conference"
> > > state.  I don't think we can assume that the desired liveliness of the
> "in
> > > conference" state is proportional to the liveliness of the media
> exchange.
> > >
> > > How about something like a DURATION or TTL parameter on the INVITE?
> So,
> > > the meaning would be something like "I invite you to be in conference
> with
> > > me for the next 4 minutes."  Re-INVITEs would need to be sent
> periodically
> > > to keep the conference going.  I have not got into the spec enough to
> > > understand all of the implications of this, but it seems
> straightforward in
> > > principle.
> > 
> > Note that the session description (at least for SDP) already has
> > duration information. INVITE does have an Expires header. See the
> > following text:
> > 
> > For {\INVITE} requests, it is a request and response-header field.  In a
> > request, the caller can limit the validity of an invitation, for
> > example, if a client wants to limit the time duration of a search or a
> > conference invitation.  A user interface {\MAY} take this as a hint to
> > leave the invitation window on the screen even if the user is not
> > currently at the workstation.  This also limits the duration of a
> > search.  If the request expires before the search completes, the proxy
> > returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
> > response, a server can advise the client of the maximal duration of the
> > redirection.
> 
> The Expires header is close but not the same thing we are talking about,
> though. Expires limits the duration of the invitation, not the session.
> Once the invitation is accepted, the Expires header has no meaning. 
> 
> -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: [email-masked] (Adam B. Roach)
Date: Thu, 21 Jan 1999 15:20:51 -0600 (CST)

>From: Henning Schulzrinne <[email-masked]>
>I don't think there's any reasonable way to prevent DOS attacks except
>possibly to keep track of call states owned by a single previous hop and
>take protective measures if this number exceeds some threshold. 
>...
>I don't think that keep-alives can protect against DOS attacks.

Not by themselves; they can, however, add a requirement that the
"attacker" have sufficient resources to not only send the initiation
messages, but also to respond to the subsequent PINGs. I don't see
PING as a solution to the problem (that needs to be addressed more
at the level of a site-wide security policy) as much as a built-in
deterrent in the case of overly-simplistic or misconfigured proxies.

[And, in a different message]

>On a more tactical note, I would think that given the uncertainty as to
>what's desired, we should not try to modify the current spec, about to
>be declared a proposed standard, but rather work on an extension, since
>SIP has a pretty clean method of adding those. We can then experiment
>with different options and proceed as we gain confidence in the
>solution.

Given that support of any keepalive mechanism should be mandatory
in order to be at all useful, it seems a bit shortsighted to leave 
it out of the first version of the specification, does it not?

---------------------------------------------------------------------------

>From: "Donovan, Steven R. (MCI)" <[email-masked]>
>

(e.g. SUBSCRIBE/NOTIFY) 

While such a mechanism would solve the problem within the current
framework of the protocol, there are a couple of issues:

a) As I mentioned above, to be useful, a keep-alive must be
   mandatory (otherwise, you'll have some stateful proxy servers unable
   to interoperate with clients which are compliant or conditionally
   compliant). SUBSCRIBE and NOTIFY should probably remain optional
   for a client due to their level of complexity. (Could we even
   make them mandatory, since they're in a separate document?)

b) This implementation requires the addition of timers in a client.
   Currently, a simple, single-threaded client without re-entrancy or
   complicated signal handling is possible. By adding a timer
   requirement on the clients, this all changes.

As Henning has pointed out, simply making parts of the specification
mandatory does not make them happen. More difficult parts of the
standard will go unimplemented in many cases, regardless of the
strength of the requirement on paper.

>response is received within a predefined time then the proxy would tear down

 From an implementation point of view, this adds only the requirement
to handle one more message, in a method very similar to other messages.
In fact, for most client implementations, the code to handle a PING
can be identical to that handling a BYE, except without cancelling
a session. Supporting this additional method would require a single 
well-placed "break" or "return" statement, in most cases. (Not to
let my language bias show through, but I think it gets the idea across).

>expires time of a session.

a) As in option 1), this adds substantial complication to the client
   implementation, through the use of timers which interrupt other
   processing (since the client must re-INVITE periodically). 

b) This solution pushes the decision to send keep-alive messages from 
   the proxies down into the clients. In most cases, the clients can 
   negotiate this directly through some more appropriate level, such 
   as a media exchange.

>The third approach seems to minimize the amount of messaging required.

I'm not sure how; for each call-confirmation period, there would be
three messages passed back and forth (INVITE, response, ACK). This
looks like it is the most message-intensive proposal so far.

(Actually, a non-recurring SUBSCRIBE/NOTIFY implementation would be
even more expensive, requiring a four message "SUBSCRIBE, response,
NOTIFY, response" sequence).

>other options and criteria that should be factored into the analysis?

I think that the addition of a method which is mandatory for UAS
implementations should be as simple as possible, to ensure universal
support. As we've seen in other protocols, even if a requirement
is considered mandatory, if it is too difficult then it will fall
between the cracks for enough clients to be useless for the others.

If message overhead is such a major concern, we could define a behaviour
for PING that results in one message per period in a compliant case,
and two per period in a conditionally compliant case. By adding a
header to the ping method, "Period," we can request that the client
re-send a ping response every n seconds. If the proxy fails to hear
from the client within that time period, it re-sends a PING. By making
support of the "Period" header a SHOULD, we allow simple clients to
wait for the proxy retransmission, while giving more savvy clients
the capability to cut down on network traffic by sending pre-emptive
responses. The only problem with this is that it introduces the
concept of multiple final responses for a message (unless we add
a 1xx-class message as the recurring response to a PING -- which
may be a useful differentiation anyway, since it will let the
requesting server know whether to expect future periodic responses).

(For those not wanting to add another header, re-use of "Expires"
or "Retry-After" might be possible, if a bit inconsistant.)

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jan 1999 19:51:00 -0500

Adam B. Roach wrote:

> it out of the first version of the specification, does it not?

It still seems to me that this is largely a non-issue. The spec
currently says a BYE SHOULD be sent, and under normal situations, it
will. With Record-Route, this means a stateful proxy will know the
session state in most cases. So, we have yet to see if this is really a
problem.

> framework of the protocol, there are a couple of issues:

SUBSCRIBE and NOTIFY are not at all what I interpet this to mean. To me,
it means that the caller periodically retransmits the INVITE to keep the
session "alive" at stateful proxies and the UAS. Should the caller fail
to send it, or should the callee fail to respond, all parties involved
would then know the session has ended non-gracefully.

Doing this is easy. We add a header field called "Refresh", which is set
by the UAC in the re-INVITEs. Proxies MAY increase the value as the
re-INVITE is forwarded, but shouldn't decrease it. The UAS MAY then
increase it, and reflect the final value in the response. All stateful
proxies and the UAC then note the refresh value. The UAC must then
re-issue an INVITE before the time expires. If it doesn't everyone knows
the call is terminated. This solution requires the UAC to know about it.
It can be optional (and thus no Require header placed in the request),
and the UAC and all proxies will know if the UAS doesn't support it, if
the response contains no Refresh header. If made mandatory, the UAS will
fail the response if it doesn't support keepalives.

As an alternative, SDP can already specified sessions bounded in time.
Thus, one possibility is to forgo any new header fields and simply use
this. But, if we had to choose I'd rather do it with a SIP header.

>    make them mandatory, since they're in a separate document?)

I'm unsure even how SUBSCRIBE/NOTIFY would work. Who is subscribing (the
proxies?) and to what? If they are subscribing to the event "call
terminated", this is totally redundant since BYE serves exactly this
purpose. Plus, there are security implications to allowing proxies to
subscribe to call state. SUBSCRIBE/NOTIFY doesn't give periodic
refreshes; thats the whole point - you don't need to poll.

>    requirement on the clients, this all changes.

Clients will need timers to support request/response retransmission. For
TCP, responses must still be retransmitted.

> let my language bias show through, but I think it gets the idea across).

This doesn't seem to be better in any measurable way from (1) (at least,
from my interpretation of (1). Its more messages, a new method (as
opposed to a new header), and more complex.

> >expires time of a session.

This seems identical to my interpretation of (1), but I don't see why
the proxy needs to send a BYE. Since the user agents know about this
mechanism, if the timeot expires all parties involved will know and the
call terminates without having to send a BYE.

> requesting server know whether to expect future periodic responses).

This notion of not resending the PING request doesn't work with UDP,
since request retransmissions are needed to ensure reliability.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Jan 1999 21:25:43 -0500

Jonathan Rosenberg wrote:

> fail the response if it doesn't support keepalives.

How is the refresh interval set?

> refreshes; thats the whole point - you don't need to poll.

One way I've interpreted this is that whoever wants a liveness
indication subscribes to the event 'timer expiration', which will
trigger either a one-time or periodic (depending on the definition of
events) notification.

> TCP, responses must still be retransmitted.

Also, even a basic system will need timers for ARP and other low-level
protocol things, so this is not a big deal.

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

---

From: [email-masked] (Adam B. Roach)
Date: Thu, 21 Jan 1999 21:05:03 -0600 (CST)

>From: Jonathan Rosenberg <[email-masked]>

>session state in most cases. So, we have yet to see if this is really a

I can tell you, from the persepctive of implementing a proxy right
now, that _it_ _is_ _a_ _problem_. "Most cases" does not work, since
the exceptions will pile up call records until the proxy is restarted
(which, in a carrier class network, should be months or even years
of operation). Not addressing this problem makes SIP entirely
useless for value added service implementation at the server level,
which is something that many operators are very interested in.

>session "alive" at stateful proxies and the UAS.

I beleive you are describing option (3), below.

[on the re-INVITE keepalive solution]:
>This solution requires the UAC to know about it.

Therein lies the first problem.

>It can be optional...

This is the second.  

If a *proxy-originated* method of determining the "liveness" of
a session is not made *mandatory*, like I said above, the implementation 
of most value added services at the server level becomes impossible.

I'm not just blindly asserting this; I gave a good example in my
original message last week. I'm running into this very real problem 
right now as I sit here implementing a SIP server. Without support from
the protocol, there is no solution.

Let me summarize:

A proxy may be keeping track of a call during its entire
duration (there are a number of reasons this may be done).
This is effected by using Record-Route. If, however, a BYE 
fails to arrive (for whatever reason) at the termination of 
a call, the proxy must know to delete the call record. If the
proxy deletes a call record before a session is terminated
(by timeout, for example), it makes the routing of subsequent
call messages impossible (since the information regarding the
ultimate destination of an INVITE may no longer be available).
Without the ability for a proxy server to check the liveness
of a session, there is no way to rectify this problem.

>this. But, if we had to choose I'd rather do it with a SIP header.

I agree that this should be done in SIP, not SDP. Proxies should not be 
required to interpret the payload of their messages; they should merely 
forward them.

>refreshes; thats the whole point - you don't need to poll.

I'm not sure how much discussion of this topic has been done on the
mailing lists, so perhaps I'm assuming too much. Henning has offered
the idea that the SUBSCRIBE/NOTIFY mechanism be extended to include
a more general mechanism for learning more about what is going on.
In this case, you'd be subscribing for either a periodic notification
of a session's existance or an immediate notification of it. The 
latter case is hardly worth considering, since it involves four
messages per period. The former is lightweight (from a protocol
point of view, not an implementaiton one), but requires mandatory
client support to fix the problem I'm describing.

>TCP, responses must still be retransmitted.

True; however, these can be done serially with, for example, a timeout
in a select() statement. Adding timers during the session itself requires
an interruption of call-related processing by a periodic signal.

>opposed to a new header), and more complex.

It does, however, allow the proxy to impose supervision on a session when
the clients have no reason to do so. This is absolutely necessary
for, as I've said, the implementation of value added services.

It is fewer messages: in an ideal case (a compliant client), it
sends one message per polling period (merely another conditional
response). In a conditionally compliant client, it sends two 
messages per polling period (a PING and a response). A re-INVITE,
on the other hand, will always send three messages (an INVITE, a
response, and an ACK).

The semantics of adding a new header to any of the existing methods
are very difficult, when considering the case of a proxy-initiated
keep-alive or ping system. I'm not fighting for the addition
of a new method because it sounds like fun. I'd like to solve this
problem with a little impact as possible. While there *do* appear to
be solutions in 99% of the realistic cases, that 1%, or even
1 in a million in which they fail, will add up quickly at 100 
transactions per second over the course of a year.

Beleive me, I understand the implications of adding a new method.
I'd like to avoid it, but can't see a reasonable solution otherwise.

>since request retransmissions are needed to ensure reliability.

Perhaps you misunderstand what I am suggesting. A potential
implementation would be:

A PING request would be retransmitted (T1, doubled each time, max of T2,
up to 11 times) until a provisional or final response is received. Once 
that is accomplished, it is only retransmitted at the frequency specified 
in the "Period" header. As long as another provisional response is 
received in at the freqency specified in the "Period" header, the PING
is not retransmitted.

If an 11th retransmition of a PING fails to provoke a response, we 
consider the call dead.

This allows the client to either send back a 2xx message and ignore
the "Period" (since they will be re-queried later), or to send
a 1xx message at the frequency defined by "Period" (to cut down on
network overhead).

/a

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 22 Jan 1999 10:13:44 -0600

> session state in most cases. So, we have yet to see if this

Let's say there are two endpoints on a call. They're both PCs, and both
machines crash hard due to a software bug. Who BYES? Nobody.

Who cares? Well, we already gave up on billing for the session unless it
is through a gateway (which would detect media timeout) or via a
resource reservation (which times out). So, it's not an issue from a
billing perspective.

The issue seem to be call routing towards a set of SIP endpoints which
are frontended by a location server acting as an automatic call director
(ACD). It would be nice for the ACD to know the status of all endpoints
so that it could make efficient routing decisions. Perhaps one could use
registration to determine endpoint availability? This might not detect a
crashed endpoint, so the ACD might need to send an OPTIONS to the
preferred registered target and verify its status before routing a call
to it.

> refreshes; thats the whole point - you don't need to poll.

I think the idea here was for the proxy to SUBSCRIBE to a "timestamp"
event from the client. The client would then NOTIFY the proxy
periodically. If the proxy misses some events, it would take action such
as probing the client or unlisting the client.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Jan 1999 14:13:54 -0500

> preferred registered target and verify its status before routing a call

Since the server can arbitrarily limit the lifetime of a registration,
an ACD server could set the registration expiration time to a small
value (say, one minute) and thus get an indication of application
liveness.

---

From: [email-masked] (Adam B. Roach)
Date: Fri, 22 Jan 1999 16:35:45 -0600 (CST)

>preferred registered target and verify its status before routing a call

Actually, that's not quite the scenario I'm trying to describe. The
liveness of a client is fairly easy to ascertain (using OPTIONS,
or by cranking down the Expires duration for a REGISTER).

The presence of a client, however, does not imply that every
call that has ever been started on that client is still valid.
While this may be somthing of a non-issue for clients which are
run only occasionally, it becomes somewhat problematic for, say,
voice gateways into the PSTN, which will almost always be up.

If we lose a BYE from one of these gateways (say, during a 30 second
network outage), there is currently no recovery mechanism.
The result is that we have an allocated call record hanging
around in the proxy server indefinitely. It represents a
session which has long since gone away. Ultimately, as these
records pile up, we run out of memory.

The example of the ACD *does* demonstrate quite well exactly
why such records must be maintained: after an INVITE has been
sent off, we need to keep data around to know to whom the
corresponding BYE should be routed.

It is obvious that the concept of proxy servers maintaining
a record of a call for its entire duration is expected to be
supported by the protocol, as demonstrated by the presence of
the Record-Route header. It is also obvious that the full
implications of error conditions in such a configuration have
not been fully explored.

There are two workable solutions to this problem, both of
which have been discussed. One is a mandatory or server-initiatable 
heartbeat exchange between connected clients.  The other would be 
the capability on the part of a server to poll the clients /not just
for presence/, but for the existance of an ongoing session. Either 
would work as well as each other. 

Implementation details for both solutions with single-packet network
overhead per period have been discussed, so there is no network
traffic difference.

It is my opinion that the PING option would be much less work
to implement in clients than a client keep-alive messaging, and
about as much work to implement in servers. Others have expressed
concerns about the headache of adding a new method instead of
adding new behavior for an old method.

A compromise to both positions would be the addition of some
mandatory behavior to OPTIONS; this would require clients
to check the To, From, and Call-ID headers; if it is involved
in a session which matches all three, it responds with a special
2xx code (say, 280) indicating that the call is still valid.
Any other code would be interpreted to mean that the call is
gone.

In any case, an implication of these facts is that, unless such 
provisions are added to the specification as mandatory, it will 
be nigh-impossible to implement any proxy making use of the 
Record-Route header with any sensible behavior.

This is a non-trivial shortcoming.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Jan 1999 19:27:51 -0500

"Adam B. Roach" wrote:

> corresponding BYE should be routed.

However, PSTN gateways would not be a typical example, since they would
presumably want a much quicker, media-driven aliveness mechanism, as
discussed previously.

> Any other code would be interpreted to mean that the call is

This would require a bit more specification, namely that this behavior
occurs when the body is empty (no session description), since a 2xx
status could otherwise be taken to mean that the new session description
is ok.

There is another issue with a mid-stream proxy querying a UAx as to
liveness: we can't assume connectivity transitivity, due to firewalls.
Thus, if a call goes UAC-F-P1-P2-P3-UAS, there is no guarantee (or,
rather, it's very unlikely) that P2 can directly ping UAC, since F may
only allow the TPC connection to P1. This would argue for UAC-initiated
(and UAS/P1/P2-requested) liveness indications or you'd have to use
partial Record-Routes. I'd imagine that anything that only requires
pretty much the same set of connections as was used for setup has the
largest chance for firewall success.

---

From: [email-masked] (Adam B. Roach)
Date: Mon, 25 Jan 1999 10:58:14 -0600 (CST)

Henning Schulzrinne writes:
> Dean Willis writes:

The issue is not whether the gateways are aware of call termination.
It is whether a proxy server communicating with such gateways is
able to detect it.

>partial Record-Routes. 

This would also be a viable solution; the key is that all four of
the UAS, P1, P2, and P3 in your example need to be able to request
such notification.

>I'd imagine that anything that only requires

And every liveness test I've proposed so far was expected to travel
along this path. In this case, P2 would send a ping-type command to
P1. If P1 has persistant call state, it could respond directly. If
it does not, it would query the UAS associated with the UAC on the
far left side of the chain; it would then send the response back to
P2.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jan 1999 15:12:59 -0500

> records pile up, we run out of memory.

I understand and appreciate the problem, but I'd like to explore the
deficiencies in the "time it out after X seconds" solution. I recall
from a previous mail that the problem was, for example, that a proxy
server might do time-of-day based routing, and so when the re-INVITE
comes, and the proxy has timed out the state, the re-INVITE goes to the
wrong address since the time has changed. Actually, this won't happen.
Recall that when a proxy inserts a Record-Route into the request, it
gets mirrored in the Route headers of subsequent requests. So, when the
proxy receives the re-INVITE after tearing down the state, the INVITE
will get routed correctly, since the proxy has to forward the request on
the path in the Route header, not based on its own logic. Same for the
ACD case.

So, even if a proxy times out state, requests for the call should be
routed correctly.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jan 1999 15:20:51 -0500

> far left side of the chain; it would then send the response back to

Seems a bit dangerous. P2 must trust P1 to give correct call state
information. 

-Jonathan R.

---

From: [email-masked] (Adam B. Roach)
Date: Mon, 25 Jan 1999 15:53:09 -0600 (CST)

>Jonathan Rosenberg writes:
>Adam B. Roach wrote:

Reiterating the chain of proxies:
UAx - [firewall] - P1 - P2 - ...

In this circumstance, P2 really has no choice but to trust P1 about
the state of the call. All user agent information is being proxied
by P1 under all circumstances. Are you considering this a security 
problem, or a cache coherency problem (e.g. P1 still beleives the call
to be ongoing)?

It would make sense that, if P1 has no authoritative method of knowing
whether a call is still in progress, it would query the user agent. If
it does have such information, it can save network overhead by replying
directly.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jan 1999 22:56:27 -0500

> problem, or a cache coherency problem (e.g. P1 still beleives the call

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.

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.

-Jonathan R.

---

From: [email-masked] (Adam B. Roach)
Date: Wed, 27 Jan 1999 09:41:41 -0600 (CST)

>Jonathan Rosenberg <[email-masked]> writes:
>
>Adam B. Roach wrote:
>> 

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?

Wouldn't users start avoiding that proxy and trying to find alternatives,
once they realised it was programmed by a lunatic?

>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? 

The point, of course, being that no protocol can protect against
abuses by trusted nodes. Proxy servers, by their very nature,
have to be trusted to behave in a compliant manner -- or, at the
very least, in a non-malicious one.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Jan 1999 10:42:56 -0500

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

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

> "Route:" headers, and skips P2, instead sending the keep-alive

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.