Subject: Proxy Server Inconsistancies

From: [email-masked] (Adam B. Roach)
Date: Wed, 13 Jan 1999 21:49:47 -0600 (CST)

I have run into a couple of protcol shortcomings in my attempts to 
implement the sip-11 draft.

1) Stateful proxies need to know about call termination

   For a stateful proxy which maintains per-call information, the
   fact that BYE and ACK requests related to one of its calls may bypass
   the proxy makes it very difficult to determine when a call record may 
   be safely discarded.  This also makes the stateful proxy particularly
   vulnerable to denial of service attacks by a malicious SIP client 
   repeatedly initiating calls with an INVITE which are never shutdown 
   with a BYE.

   The specified solution is to use a "Record-Route" header forcing
   all requests/responses including BYE and ACK to be sent to the SIP proxy.
   Note, however, that it is not mandatory that a client send a BYE request
   at all. Furthermore, in the case of abnormal shutdown of the SIP clien,
   (or severing of a physical link, or any number of other errors), a 
   BYE request will NOT be sent, so making BYE mandatory wouldn't even
   solve the problem.

   Timing out call leg records is not feasable, since that puts an 
   upper limit on the duration of a SIP initiated call.

   A possible solution would involve the addition of another request 
   method, "PING," which could determine if a call leg is active at the 
   ping'ed server.  The semantics of such a method (responses of 1xx, 
   200, and 481; sufficient headers to identify a leg; etc.) should
   be obvious. If anyone has any different ideas, please introduce 
   them. I can draft out some language to describe a PING method in 
   detail for possible inclusion in a future draft, if there is interest.

2) Behavior of "Contact" header's effect on BYE and ACK needs to be
   clarified.

   I beleive this is actually more of a nit than a shortcoming.

   The specification is not very clear in its description of
   INVITE 2xx responses under the Contact header; it needs to be
   specified that, if a Contact header is present, all future
   requests MUST be sent directly to that host.  I beleive this 
   is the intention of the current draft, but can't find 
   requirement-like language to that effect.  For example,
   updating 6.13, under "INVITE 2xx responses" to read "The value 
   of the Contact header MUST be copied into the Request-URI of 
   subsequent requests for this call" would fit the bill.

   There are a few scenarios where this comes into effect; most
   of them involve AIN-like services being implemented in a 
   proxy or relocation server. For example, a proxy that does
   not maintain a call record for the duration of the call (only
   until the final response from an INVITE) may choose to implement
   a service which attempts to reach a user at different locations
   based on a time table. When such a proxy receives a BYE
   request, it is unclear to which destination it should be routed,
   since it depends on the initiation time of the call -- information
   to which the proxy has no access.

   The insertion of a "Contact" field by a proxy in this and similar
   circumstances must force redirection of ACK and BYE requests to 
   prevent undesirable results.

-- 
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    |                  <*> | USA

---

From: [email-masked]
Date: Thu, 14 Jan 1999 15:49:48 -0700

I think the absence of a SIP keep-alive also complicates modularity in the
user agent.  Some specified behaviors are dependent on whether the user is
"already in the conference."  Without a SIP keep-alive, this must be
determined by extraneous mechanisms.  I.e., "have sent or received Accept,
and have not sent or received BYE" does not account for lost connectivity.
So, it seems that a SIP engine would need to consult a higher level state
machine that maintains "in conference" state e.g., by monitoring success of
media exchange and using whatever time-out it deems appropriate.  I think
it would be cleaner if the SIP engine maintained its own independent "in
conference" state.  E.g., if a particular media channel became unavailable,
there would be an opportunity to negotiate a different one within the
context of the same conference.  You could remain "in a conference" without
exchanging any media.

Tim

Tim Dorcey
iXL-Los Angeles
[email-masked]
(310) 235-3928

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Jan 1999 21:57:53 -0500

>    repeatedly initiating calls with an INVITE which are never shutdown

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. 

>    detail for possible inclusion in a future draft, if there is interest.

There may well be circumstances where a keep-alive is useful. Given the
obvious costs in terms of packets and processing, I want to be sure that
there are (a) no other alternatives, (b) we can actually gain something.
If we want to, a client can already send OPTIONS requests as
keep-alives, and the called client can do a re-INVITE. What is missing
is for a proxy to say "don't just route a request my way whenever you
feel like sending a request, generate one every N seconds".  The
complexity arises if we allow several proxies to specify different
values for N, as an emotionally unsecure proxy in constant need of being
reminded of the affection of the caller can burden all the other proxies
along the way with these keep-alive messages. I'd be far less worried if
this is primarily to time out state rather than (say) terminate billing
for a call. In that case, a keep-alive on the order of a typical call
duration (four minutes) would be sufficient and have more modest impact
on packet processing load.

For billing of PSTN-terminated calls, media-based timeout are, in my
opinion, a far better solution, as they can prevent the
phone-off-the-hook-after-a-call-to-Australia problem.

I don't think that keep-alives can protect against DOS attacks.

>    subsequent requests for this call" would fit the bill.

It does say (spec version -11):

   INVITE 2xx responses: A user agent server sending a definitive,
        positive response (2xx) MAY insert a Contact response header
        field indicating the SIP address under which it is reachable
        most directly for future SIP requests, such as ACK, within the
        same Call-ID. The Contact header field contains the address of
        the server itself or that of a proxy, e.g., if the host is
        behind a firewall. The value of this Contact header is copied
        into the Request-URI of subsequent requests for this call.

Except for the MUST, this seems pretty close.

>    to which the proxy has no access.

Good point/example.

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

---

From: [email-masked]
Date: Sat, 16 Jan 1999 15:51:20 -0700

>phone-off-the-hook-after-a-call-to-Australia problem.

I think SIP state time-out is a significant issue and at least deserves
some discussion in the spec.  E.g., I don't want to spontaneously accept a
call from someone I was connected to last week because a BYE never arrived,
and I don't want "new call" alerts to appear in the middle of conversations
due to transient network problems.  I realize that these issues can be
dealt with at the application level, but it seems awkward that SIP creates
and acts upon "in conference" state, yet requires unspecified mechanisms to
remove it.

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.

Tim

Tim Dorcey
iXL-Los Angeles
[email-masked]
(310) 235-3928

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Jan 1999 21:58:13 -0500

> on packet processing load.

I agree that if you want it, OPTIONS is precisely the method for this
function.

You can solve the "proxy telling the client the frequency for the
keepalives" problem by having the proxy send the OPTIONS request to the
UAS's of both the caller and callee, if it likes. This means that the
frequency becomes a purely local decision, and the choice has no impact
on the other proxies. Of course, it affects the user agents, but I don't
see this as a major problem there.

Note that a "ping" using an OPTIONS from a proxy can establish the
liveness of the UAS. However, it cannot be used to ascertain whether the
user is in a call or not. If the user has left the call, but never sent
a BYE (or didn't send the BYE through a proxy), its UAS will still
respond to OPTIONS requests.

> phone-off-the-hook-after-a-call-to-Australia problem.

I agree. It was argued that using session based timeouts broke the
modularity of SIP; I disagree. Modularity does not imply lack of
communication between components, but rather a clean separation of
function. Determining session liveness is best done with the protocols
and machinery of the session type. This information can then be passed
to the SIP engine, if needed.

> >    to which the proxy has no access.

Actually, I don't see this as a problem. Lets say the proxy uses a
Record-Route header, and that the UAS sends a Contact header in the
response to the INVITE. According to the spec, the UAC is supposed to
copy the Record Route contents into the Route header, and also add the
contents of the Contact header as the last host on the source route.
Now, when the UAC sends a BYE, it goes to the proxy (because of the
Route header). The proxy will know the address of the UAS to deliver it
to NOT based on the AIN logic, but based on the next address in the
Route header, which the proxy is supposed to use for the next hop
server. So, there is no problem when a Contact header is present, or
there is another proxy using Record-Route downstream from a given proxy.

Even if the proxy was the last on the Route chain, and so it delivers
the request to lots of target UAS's, the tag in the To field will ensure
that only the correct one processes the request.

> >    prevent undesirable results.

No, a proxy would insert a Record-Route for this, not a Contact header.

-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: Lars Berggren <[email-masked]>
Date: Mon, 18 Jan 1999 10:33:41 +0100

Jonathan Rosenberg wrote:
>... 

Why isn't it mandatory for a client to send a BYE when the call is to be
terminated? If it was stated in the spec that a client MUST send a BYE
when
releasing a call, I think it will help here. Together with some kind of
keep-alive mechanism you are describing ( and Record-Route support, see
below )
it would, as far as I can see, give the proxy enough information to know
when 
a call terminates. Correct me if I am wrong.

>...

This is done by UAC:s that support Record-Route. But the text to Table 6
in
sip-11 states that:
   "Headers whose support is optional for all implementations are not
shown."

And since Record-Route is not listed, I draw the conclusion that not all
UAC:s
will support Record-Route, and hence, a proxy server adding itself to a
Record-
Route header cannot be sure to receive the remaining requests for a call
leg.

Is making Record-Route mandatory for user agents a bad idea?

Thanks,
Lars Berggren

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Jan 1999 12:33:22 -0500

> and acts upon "in conference" state, yet requires unspecified mechanisms to

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.

> understand all of the implications of this, but it seems straightforward in

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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Jan 1999 13:24:34 -0500

> a call terminates. Correct me if I am wrong.

Currently, the spec says "SHOULD send a BYE". Since this means "unless
there's a really good reason not to do this, do it", this seems like
pretty close to what you want and I'm not sure it's worth arguing
whether this should really say MUST instead. As was pointed out earlier,
you can't absolutely rely on the presence of a BYE, whether the spec
says MUST or SHOULD. There may be exceptional circumstances, such as
multicast INVITEs, where a BYE may not be desirable. Also, with
one-directional multicast networks, the callee may not be able to send a
BYE. Note that a SIP implementation that doesn't send BYEs would only be
conditionally compliant, so you can send out the protocol police if a
vendor claims full compliance, but doesn't do BYE...

> Is making Record-Route mandatory for user agents a bad idea?

Yes, I believe, since it increases the complexity for minimal clients.
Again, I think you overestimate the power of specifications. Just
putting it there doesn't make all implementations do it. The higher you
raise the bar, the fewer are likely to actually comply. Record-Route is
a particular example, since many really simple implementations will send
all requests to a local proxy, who can then do "the right thing" in
terms of routing, so that you get the right effect without the UA
supporting it.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Jan 1999 15:22:49 -0500

> vendor claims full compliance, but doesn't do BYE...

Another case where BYE probably shouldn't be sent is when I invite a
user to an mbone session. In this case, the media being exchanged are
not between myself and that other user, so there is really no need for
the BYE. The session description itself in this case conveys the
duration of the session.

> terms of routing, so that you get the right effect without the UA

It is possible to separate the Record-Route processsing into two
distinct steps:

1. The Record-Route list from a response must be inverted and placed in
the Route header in subsequent requests from the UAC
2. Subsequent requests from the UAC are sent to the first server on the
Route list

(1) can be made mandatory (SHOULD strength), but (2) can be MAY. A UAC
can send a request directly to a preconfigured proxy always, without
removing the top Route header. The proxy can then look at the Route
headers and forward the request to the first proxy, as it normally
would. A proxy would need to additionally check that the top proxy on
the list is not itself, however.

As Henning has mentioned, there are issues though in that we are going
to proposed very soon.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Jan 1999 15:27:11 -0500

Henning Schulzrinne wrote:

> response, a server can advise the client of the maximal duration of the

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.