Subject: [sipcore] 3265bis Open Issue: Timer N and Resubscribes

From: Adam Roach <[email-masked]>
Date: Fri, 14 Aug 2009 15:53:32 -0500

One of the things we discussed in Stockholm was whether a Timer N 
expiration on resubscribe causes the subscription to be terminated. This 
was posed as a purely theoretical situation, with no concrete 
circumstances in mind under which it might occur.

(As a refresher: Timer N is the timer run between sending a SUBSCRIBE 
and receiving a NOTIFY. For the initial SUBSCRIBE, the expiration of 
Timer N causes the subscription set up to fail. This was called Timer L 
in 3265bis-00, but is being renamed Timer N to avoid colliding with 
invite-fix).

I've given a lot of thought to what set of circumstances would lead to 
conditions in which the SUBSCRIBE 200 response is arriving just fine, 
but the NOTIFY is being consistently lost (at least, consistently enough 
for Timer N to expire). The only plausible scenarios I've been able to 
construct involve some signaling intermediary changing an address 
association in the middle of a subscription.

For example: imagine a client behind a NAT uses STUN to determine a 
viable public address/port combination. It then composes an initial 
SUBSCRIBE message and sends it off to the notifier. The initial NOTIFY 
arrives just fine.

Later in the subscription, the NAT resets the association between the 
subscriber and the external NAT port.

Because of the Via header field received and rport parameters, the 200 
responses to SUBSCRIBE messages will continue to be routed back to the 
subscriber. However, because the address/port in the Contact no longer 
route back to the subscriber, the NOTIFY messages will never arrive.

This behavior can also arrive if the local address for a machine changes 
-- say, due to a DHCP address assignment changing, or a PPP tunnel being 
re-established with a different IP address.

In all of these cases, I think it's pretty obvious that there is no hope 
of the subscription ever recovering. Leaving it lying around until it 
expires has no benefits, and wastes resources at both the subscriber and 
the notifier. On top of that, it give the subscriber application the 
impression of being subscribed to state changes, when none will ever 
actually arrive.

For these reasons, I would strongly recommend that the expiration of the 
new supervisory timer (Timer L in 3265bis-00, Timer N in the forthcoming 
3265bis-01) during a re-subscribe result in the subscription being 
terminated.

/a

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Aug 2009 16:49:40 -0500

At 03:53 PM 8/14/2009, Adam Roach wrote:
>expiration on resubscribe causes the subscription to be terminated. 
>This was posed as a purely theoretical situation, with no concrete 
>(As a refresher: Timer N is the timer run between sending a 
>SUBSCRIBE and receiving a NOTIFY. For the initial SUBSCRIBE, the 
>expiration of Timer N causes the subscription set up to fail. This 
>was called Timer L in 3265bis-00, but is being renamed Timer N to 
>avoid colliding with invite-fix).
>
>I've given a lot of thought to what set of circumstances would lead 
>to conditions in which the SUBSCRIBE 200 response is arriving just 
>fine, but the NOTIFY is being consistently lost (at least, 
>consistently enough for Timer N to expire). The only plausible 
>scenarios I've been able to construct involve some signaling 
>intermediary changing an address association in the middle of a subscription.
>
>SUBSCRIBE message and sends it off to the notifier. The initial 
>NOTIFY arrives just fine.
>
>Later in the subscription, the NAT resets the association between 
>the subscriber and the external NAT port.
>
>Because of the Via header field received and rport parameters, the 
>200 responses to SUBSCRIBE messages will continue to be routed back 
>to the subscriber. However, because the address/port in the Contact 
>no longer route back to the subscriber, the NOTIFY messages will never arrive.
>
>This behavior can also arrive if the local address for a machine 
>changes -- say, due to a DHCP address assignment changing, or a PPP 
>tunnel being re-established with a different IP address.

I think you had me swayed until this comment (which gives your whole 
conclusion more context). Are you suggesting the actual time in which 
a SUB/200OK transaction take place, and the sending of the NOTIFY 
following that 200OK (most likely along the same message path, and 
may be consecutive datagrams from that entity) that a DHCP client 
(the subscribed to entity) changes its IP address, therefore the 
200OK (i.e., the acceptance of the subscription) is either from a 
stale IP address or just plain invalid?

I'm sorry, but I find this scenario to be way beyond most outlier 
scenarios for this document to have to worry about.

I mean - we're talking about a reSUBSCRIBE here - where there is a 
valid subscription already; meaning if anything has changed - this 
should be apparent during the reSUBSCRIBE transaction, shouldn't it 
(otherwise, what's the point)?

Therefore I counter-propose what I said at the mike in Stockholm, 
that if the 200OK is received, the subscription is considered good - 
regardless of receiving the NOTIFY. The subscribed-to entity accepted 
the subscription, and that should be it, especially if the 200OK is 
received by the UAC (subscribing entity).

That said, it is obvious that the failure to receive a 200OK to a 
reSUBSCRIBE is cause for termination of the subscription - as is the 
current practice.

BTW - how can't this scenario be true for new subscriptions?

>In all of these cases, I think it's pretty obvious that there is no 
>hope of the subscription ever recovering. Leaving it lying around 
>until it expires has no benefits, and wastes resources at both the 
>subscriber and the notifier. On top of that, it give the subscriber 
>application the impression of being subscribed to state changes, 
>when none will ever actually arrive.
>
>For these reasons, I would strongly recommend that the expiration of 
>the new supervisory timer (Timer L in 3265bis-00, Timer N in the 
>forthcoming 3265bis-01) during a re-subscribe result in the 
>subscription being terminated.
>
>/a
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Aug 2009 11:25:27 -0500

James M. Polk wrote:
>> Timer N causes the subscription set up to fail. This was called Timer 
>> L in 3265bis-00, but is being renamed Timer N to avoid colliding with 
>> invite-fix).
>>
> following that 200OK (most likely along the same message path, and may 
> be consecutive datagrams from that entity) that a DHCP client (the 
> subscribed to entity) changes its IP address, therefore the 200OK 
> (i.e., the acceptance of the subscription) is either from a stale IP 
> address or just plain invalid?

No. I'm talking about the client's transport address changing due to 
some event it may not notice -- such as a NAT binding change, a DHCP 
address change, or a PPP tunnel reestablishment -- after the initial 
subscribe, but before the resubscribe. Something like:

     Subscriber              NAT              Notifier           STUN Server
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |Binding Request    |                   |                   |
          |---------------------------------------------------------->|
          |                   |                   |                   |
          |New port binding is to 10.20.30.40:12345                   |
          |                   |                   |                   |
          |Binding Response   |                   |                   |
          |(10.20.30.40:12345)|                   |                   |
          |<----------------------------------------------------------|
          |                   |                   |                   |
          |SUBSCRIBE          |                   |                   |
          |Contact: <10.20.30.40:12345>           |                   |
          |-------------------------------------->|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |Via is tagged with "rport=12345"       |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |200                |                   |                   |
          |(sent to 10.20.30.40:12345)            |                   |
          |<--------------------------------------|                   |
          |                   |                   |                   |
          |NOTIFY             |                   |                   |
          |(sent to 10.20.30.40:12345)            |                   |
          |<--------------------------------------|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |200                |                   |                   |
          |-------------------------------------->|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |30 Minutes Pass    |                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |NAT Binding expires|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |SUBSCRIBE          |                   |                   |
          |Contact: <10.20.30.40:12345>           |                   |
          |-------------------------------------->|                   |
          |                   |                   |                   |
          |New port binding is to 10.20.30.40:9999|                   
|                   |
          |                   |                   |                   |
          |Via is tagged with "rport=9999"        |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |200                |                   |                   |
          |(sent to 10.20.30.40:9999)             |                   |
          |<--------------------------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |No binding, so NOTIFY is dropped       |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   |<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |NOTIFY             |                   |
          |                   |(sent to 10.20.30.40:12345)            |
          |                   X<------------------|                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |
          |                   |                   |                   |

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Aug 2009 12:59:34 -0500

At 11:25 AM 8/18/2009, Adam Roach wrote:
>>>expiration on resubscribe causes the subscription to be 
>>>terminated. This was posed as a purely theoretical situation, with 
>>>no concrete circumstances in mind under which it might occur.
>>>
>>>I've given a lot of thought to what set of circumstances would 
>>>lead to conditions in which the SUBSCRIBE 200 response is arriving 
>>>just fine, but the NOTIFY is being consistently lost (at least, 
>>>For example: imagine a client behind a NAT uses STUN to determine 
>>>a viable public address/port combination. It then composes an 
>>>initial SUBSCRIBE message and sends it off to the notifier. The 
>>>initial NOTIFY arrives just fine.
>>>
>>>200 responses to SUBSCRIBE messages will continue to be routed 
>>>back to the subscriber. However, because the address/port in the 
>>>Contact no longer route back to the subscriber, the NOTIFY 
>>>messages will never arrive.
>>>
>>>changes -- say, due to a DHCP address assignment changing, or a 
>>>PPP tunnel being re-established with a different IP address.
>>
>>I think you had me swayed until this comment (which gives your 
>>whole conclusion more context). Are you suggesting the actual time 
>>in which a SUB/200OK transaction take place, and the sending of the 
>>NOTIFY following that 200OK (most likely along the same message 
>>path, and may be consecutive datagrams from that entity) that a 
>>DHCP client (the subscribed to entity) changes its IP address, 
>>therefore the 200OK (i.e., the acceptance of the subscription) is 
>>either from a stale IP address or just plain invalid?
>
>subscribe, but before the resubscribe.

nice flow chart...

can't you merely mandate a new Binding Request before each 
SUBSCRIBE/reSUBSCRIBE?

If that doesn't cut it, then when the binding times out (and without 
the reSUBSCRIBE), don't the original NOTIFYs also die at the NAT 
(thus making NATs evil -- oh yeah, they already are evil)?

>Something like:

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Aug 2009 14:24:49 -0500

> can't you merely mandate a new Binding Request before each 

There's a distinct rat hole in that direction that I don't think we want 
to go down in RFC 3265bis (do we also check for VPN liveness? Collect 
local IP addresses again? Verify the IPv6 tunnel? Ping the Teredo 
server? Contact the DHCP server again to make sure the address is still 
issued to us? The actions here are virtually boundless).

It's much bigger than just SUBSCRIBE/NOTIFY -- it affects all dialogs. 
In theory, the proper solution is to use sip-outbound. In practice, 
architects, implementors, and deployers don't always make the optimal 
choice.

More to the point: we haven't, in *any* SIP document, gone about 
normatively specifying anything about when or how a client determines 
which addresses belong to the local machine or then to acquire new 
information.

> the reSUBSCRIBE), don't the original NOTIFYs also die at the NAT (thus 
> making NATs evil -- oh yeah, they already are evil)?

It does, and they are. We can't fix the evil here -- but I'm concerned 
about amplifying it, 11 messages at a time.

Keep in mind that the scenario I described was an attempt to find a 
plausible set of circumstances in which the SUBSCRIBE 200 would reliably 
arrive at a subscriber, but in which the NOTIFY would consistently fail 
to do so. And, in this case, I would argue that the proper behavior is 
to drop the subscription (since it's never going to recover).

Unless we can come up with some other plausible scenario that leads us 
to a different conclusion, I would think this is the correct answer in 
general.

/a

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Aug 2009 16:45:28 -0500

At 02:24 PM 8/18/2009, Adam Roach wrote:
>There's a distinct rat hole in that direction that I don't think we 
>want to go down in RFC 3265bis (do we also check for VPN liveness? 
>Collect local IP addresses again? Verify the IPv6 tunnel? Ping the 
>Teredo server? Contact the DHCP server again to make sure the 
>address is still issued to us? The actions here are virtually boundless).
>
>It's much bigger than just SUBSCRIBE/NOTIFY -- it affects all 
>dialogs. In theory, the proper solution is to use sip-outbound. In 
>practice, architects, implementors, and deployers don't always make 
>the optimal choice.
>
>normatively specifying anything about when or how a client 
>determines which addresses belong to the local machine or then to 
>acquire new information.
>
>>If that doesn't cut it, then when the binding times out (and 
>>without the reSUBSCRIBE), don't the original NOTIFYs also die at 
>>the NAT (thus making NATs evil -- oh yeah, they already are evil)?
>
>It does, and they are. We can't fix the evil here -- but I'm 
>concerned about amplifying it, 11 messages at a time.
>
>plausible set of circumstances in which the SUBSCRIBE 200 would 
>reliably arrive at a subscriber, but in which the NOTIFY would 
>consistently fail to do so. And, in this case, I would argue that 
>the proper behavior is to drop the subscription (since it's never 
>going to recover).

ok - I'm not going to argue that logic

Remind me what you have this timer default set to for allowing the 
SUBSCRIBE 200 to be received before determining the NOTIFY isn't coming (ever)?

>Unless we can come up with some other plausible scenario that leads 
>us to a different conclusion, I would think this is the correct 
>answer in general.
>
>/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Aug 2009 17:44:15 -0500

James M. Polk wrote:
>> Teredo server? Contact the DHCP server again to make sure the address 
>> is still issued to us? The actions here are virtually boundless).
>>
>> consistently fail to do so. And, in this case, I would argue that the 
>> proper behavior is to drop the subscription (since it's never going 
>> to recover).
>

It's defined as 64 * T1 -- which would be 32 seconds by default.

/a

---

From: Michael Procter <[email-masked]>
Date: Wed, 19 Aug 2009 14:47:51 +0100

2009/8/18 Adam Roach <[email-masked]>:
> arrive at a subscriber, but in which the NOTIFY would consistently fail to
> do so. And, in this case, I would argue that the proper behavior is to drop
> the subscription (since it's never going to recover).
>
> Unless we can come up with some other plausible scenario that leads us to a
> different conclusion, I would think this is the correct answer in general.

Doesn't this lead to an unfortunate interaction with
draft-ietf-sipcore-subnot-etags-02, in particular section 6.3
(Suppressing NOTIFY Requests)?

Michael

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Aug 2009 09:32:28 -0500

> (Suppressing NOTIFY Requests)?

We should definitely include text that indicates that the subscriber 
doesn't run Timer N when it doesn't expect a NOTIFY -- such as when they 
receive a 204 response to an in-dialog SUBSCRIBE.

/a

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 20 Aug 2009 04:43:19 -0000 (UTC)

> which addresses belong to the local machine or then to acquire new
...
> to a different conclusion, I would think this is the correct answer in

What you have here is Yet Another Argument for layering and having a
session-level protocol that detects liveness, upon which we would then
provide a transactional layer with a fixed set of transaction types, which
could then be used for an infinite set of applications.

Given that SIP isn't built that way, dropping the subscription on NOTIFY
failure seems to be about the best we can do.

--
Dean

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Aug 2009 11:47:39 -0500

>failure seems to be about the best we can do.

I'm curious how often anyone thinks this scenario will (not can) occur?

i.e., are there any complaints by vendors saying effectively "we code 
to the spec, yet this scenario still occurs (X often) and we need it 
fixed"... (presumably the operators would be complaining to their 
vendors for bad user experiences)