Subject: RE: [SIP] First cut review of Session Timer draft.

From: Steve Donovan <[email-masked]>
Date: Wed, 9 May 2001 10:04:13 -0400

Ben,

Thanks for the comments.  See my notes below...

Steve

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2001 11:57 AM
> To: Steve Donovan; Jonathan Rosenberg
> Cc: Rakesh Shah; [email-masked]'
> Subject: [SIP] First cut review of Session Timer draft.
> 
> 
> Here are my first cut comments on session-timer for the 
> upcoming last-call.
> Most of these are minor comments. Please forgive me if I am 
> re-opening old
> discussions, as I did not follow the original session-timer work. 
> 
> Comments referring to specific parts of the document are prefixed with
> (page:paragraph)
> 
> Global - We might need language (perhaps in security 
> considerations) that
> recommends against using session-timer for billing purposes with out
> additional corroboration. I can imagine a theft-of-service 
> attack where the
> UAs collude in letting the session expire, but maintain the 
> RTP session. Any
> proxy in the middle would assume the call was over. This will 
> not work if
> the timer controls a firewall, but it could if the timer was 
> only used to
> establish end-of-call for billing purposes.

While I agree that session timer should not be used for billing, I'm not
sure we want to get into the business of listing all of the things that
extensions should not be used for.  However, I will add some words into the
early sections of the document.  I propose the following:

"Note that use of SIP messages, even with the session timer extension,
should not be considered sufficient to determine the existence of sessions.
Rogue user agents can continue media sessions even after BYE messages are
exchanged.  As such, the session timer extension should not be considered as
a fix to SIP that enables reliable usage billing."

> 
> Global - (nit) there are several sections where the normative 
> language is
> not clear. For example, it often says "X does Y" instead of 
> "X MUST|MAY|etc
> do Y." Most of these are in the early descriptions, so 
> perhaps the intent is
> to reserve normative language for the specific behavior 
> descriptions later
> in the draft. If that is so, then it is not consistent.

I will strive to make it more consistent.  However, any where that a
MUST|SHOULD|MAY|ect appears should be considered normative.  Please let me
know if there are specific instances where use of the normative language in
the earlier sections of the document is not consistent with the protocol
description section.

> 
> 3:2-A proxy can lower but not increase the expiration time. 
> Jonathan brought
> up the issue of a DoS attack using insanely small 
> expirations. If a proxy
> cannot increase the expiration, it at least needs the option 
> of rejecting
> requests with expiration values below a threshold.

This should be addressed in my proposal to come to consensus on Jonathan's
thread.

> 
> 3:4 - (Typo) Sentence "They UAS MAY..." should read "The UAS MAY..."

Changed...

> 
> 3:4 - (Minor) I am not sure I see the value in pushing 
> responsibility back
> to a supporting UAC, if the UAC did not request the timer in the first
> place. Why not just let the UAS deal with it, if the UAS is 
> the element that
> wishes to use a timer? At least it might make sense to say 
> that the UAS must
> insert the Required header IF it wishes the UAC to handle the 
> re-invites.

It is a little more straight forward to specify it this way.  The added
overhead of having the UAC to the refreshes should not be enough to worry
about.  It is true that it can work in other ways, but I would like to
restrain from making changes to procedures that work, given that this draft
is pretty mature and there are likely to be implementations out there that
follow the current definition.

> 
> 4:5  What happens if the UAC does _NOT_ include a 
> Session-Expires header on
> the re-invite? I assume everyone resets their timers with the original
> values? Or does timer processing cease?

Then the re-INVITE is not a session refresh and has no effect on an existing
session timer request.  There is no requirement to include the
session-expires header on all re-INVITEs.  I will add the following wording
to the draft:

"While it will generally be more efficient for supporting UAs to include the
session-timer header in all re-INVITEs associated with a timed session, it
is not required.  Re-INVITEs during a timed session that are sent for
reasons other than refreshing the session time are allowed to not contain
the session-timer header.  The existing session timer is not changed if a
re-INVITE is received without a session-timer header."

> 
> 5:2 - Doesn't option of absolute time imply an assumption 
> that all elements
> have their clocks reasonably synchronized?

I think this has already been addressed by other responses (date header...).

> 
> 5:3 - Again, we need to allow elements to reject expirations below a
> configured threshold.

I agree.  This is addressed in my response to Jonathan's proposal.

> 
> 10:2 - How can a proxy know that it is the closes proxy to 
> the UAC that
> cares about the timer? Except in the trivial case where the 
> proxy is the
> closest to the UAC period, this seems problematic.

I think Adam has already addressed this in a previous response.

> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 9 May 2001 10:10:43 -0400

-----Original Message-----
From: Adam Roach (EUS) [mailto:[email-masked]]
Sent: Wednesday, April 25, 2001 5:55 AM
To: Ben Campbell; Steve Donovan; Jonathan Rosenberg
Cc: Rakesh Shah; [email-masked]'
Subject: RE: [SIP] First cut review of Session Timer draft.

Comments on the comments... :) 
/a 

> have their clocks reasonably synchronized? 
3:1 - "Any entity that inserts 
       a Session-Expires header with an absolute time MUST also insert a 
       Date header into the message. This ensures proper operation for 
       devices that do not have access to absolute time." 

Perhaps this sentance doesn't have enough hoopla about it, since 
I've had to point it out numerous times to different people. To those 
of you who have overlooked it (or even those you who haven't): do you 
have any suggestions about how to make it stand out more? Does it need 
better proximity to the paragraph explictly allowing absolute times 
(in section 5)? 

SRD> I have made it a paragraph of it's own (in the same place).  Hopefully
this will make it stand out.

> closest to the UAC period, this seems problematic. 

Because the *first* proxy that cares will *add* a "Session-Expires" 
header. Other proxies will merely notice (and occasionally 
adjust) it. So, if you see no "Session-Expires," you're the first node 
that cares. If you don't, you aren't. 

A clarification to this effect would probably be useful... 

SRD> It's already there, in 10:2 - "...For the proxy closest to the UAS, the
final response to the \INVITE does not contain a Session-Expires header..."

/a

---

From: Steve Donovan <[email-masked]>
Date: Thu, 10 May 2001 08:12:46 -0400

Brett,

You're correct, I had forgotten that was there.  This just shows that the
session timer draft has been hanging around too long and needs to be
promoted to RFC.

Thanks for pointing this out.

Steve

> From: Brett Tate [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2001 10:46 PM
> To: 'Steve Donovan'; [email-masked]
> > > Timer processing ceases unless re-added 
> > > by proxy or UAS.
> > 
> > No, the timer is not effected.  I have added wording to make 
> > this clear.
> > 
> 
> Last paragraph page 12 draft-ietf-sip-session-timer-04:
> "Note that if the 200 OK to the re-INVITE has 
> no Session-Expires, no expiration time exists for the 
> session.  This can happen if the proxies and/or UAS 
> change their mind about session timers, and decide 
> they no longer wish to use them."
> 
> Please continue to require this renegotiation of
> Session-Expires stuff in all re-INVITE combinations
> for the following reasons.
> 1) A revived proxy can be aware of Session-Expires value.
> 2) A revived UAS that was required to perform session 
>    extensions will know it needs to do so.
> 3) It allows the session timing to be 
>    discontinued and the call still remain.
> 4) It requires the smurf that required small timer 
>    values to stay in the picture if they want to 
>    continue to require small values.
> 
>