Subject: [sipcore] draft-jones-sip-options-ping-00: comments

From: Brett Tate <[email-masked]>
Date: Sat, 3 Apr 2010 10:08:59 -0700

Glad to see someone attempting to capture the currently common use for OPTIONS.

Here are a few comments.

Thanks,
Brett

---------

To help avoid receiving ignored data within 200 response, I recommend use of an option-tag (such a options-ping) or something else included within OPTIONS to clearly indicate that the sender does not actually want all the data which can be provided within 200 response.

Section 5.1 indicates "To avoid unduly taxing a receiving SIP entity, transmitters of OPTIONS messages MUST honor the Retry-After header field if received."  The MUST requirement is likely too strong because of implications when included within a 503.  The MUST requirement is likely also too strong because of vulnerability to quit sending requests to that device for an extremely long time because attacker or bug caused the 503 to be sent containing Retry-After with an extremely large value.

Concerning receiving 503 with Retry-After, to what does it apply:
1) OPTIONS request target ip-address,
2) OPTIONS response source ip-address,
3) both 1 and 2,
4) something else.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 3 Apr 2010 22:39:19 -0400

Brett,

> Glad to see someone attempting to capture the currently common use for

Thanks... indeed, this looked like an area that needed addressing to us.

> To help avoid receiving ignored data within 200 response, I recommend
> use of an option-tag (such a options-ping) or something else included
> within OPTIONS to clearly indicate that the sender does not actually
> want all the data which can be provided within 200 response.

I'm not opposed to this, per se, but we were trying to avoid introducing any
new signaling features at all.  If folks thought it might be useful, we can
do that.  One problem, though, is that all devices would immediately be
non-compliant ;-) 

I thought about the implications of this a little before writing the draft.
If a SIP message is sent between two SBCs, for example, quite likely the
receiving device is going to reply with something that's pre-configured
(perhaps even pre-composed) and the receiver is only going to look at the
status code of the reply.  So, I wondered whether it would even matter.

> Section 5.1 indicates "To avoid unduly taxing a receiving SIP entity,
> transmitters of OPTIONS messages MUST honor the Retry-After header
> field if received."  The MUST requirement is likely too strong because
> of implications when included within a 503.  The MUST requirement is
> likely also too strong because of vulnerability to quit sending
> requests to that device for an extremely long time because attacker or
> bug caused the 503 to be sent containing Retry-After with an extremely
> large value.

Perhaps you're right, but do you have suggestions for alternative wording?
Are you suggesting to replace "MUST" with "SHOULD"?

> 2) OPTIONS response source ip-address,

I'm a little confused by your question. Are you asking whether it applies to
the target address to which the sender of the OPTIONS sent the request or to
the address from which the recipient returned a 503, or the address of an
intermediary?

I would say it refers to the address to which the request was sent.  If
you're concerned that a reply might come from an intermediary or a rogue
endpoint, I suppose you have reason for concern.  That said, one should not
have an intermediary in the path, as it somewhat defeats the purpose.  If
it's a security issue, I would say one needs to consider the security of
messages just as they would any other message.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Apr 2010 00:49:35 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul E. Jones
> Sent: Saturday, April 03, 2010 10:39 PM
> 
> [snipped text, but topic is option-tags]
>

I was worried about this too ('cause I also suggested option-tags and was worried about code-changes), but ISTM this is basically already the case: unless most folks do exactly what this doc says today, they're non-compliant and would require changing either code or config.

The thing is, afaict, many folks DON'T do what the doc says.  Not exactly, which is the same thing (right?).  For example, of three rather popular vendors I just looked at OPTION-ping traces of, none used the 486 for anything.  I don't know what they'd do if they got one.  All 3 of the vendors use 503 to signal "out-of-service" back, but at least 2 of them still allow (and want/expect to receive) in-dialog messages - I can't tell with the 3rd.  And one of them still _sent_ all messages even if it got a 503. 

-hadriel

---

From: Brett Tate <[email-masked]>
Date: Sun, 4 Apr 2010 08:36:29 -0700

> I'm not opposed to this, per se, but we were trying to avoid
> introducing any new signaling features at all.  If folks thought 
> it might be useful, we can do that.  

Yes; it would be useful for both the sender and receiver.

> One problem, though, is that all devices would immediately be non-compliant ;-)

That is okay with me.

> > Section 5.1 indicates "To avoid unduly taxing a receiving SIP 
> > entity, transmitters of OPTIONS messages MUST honor the 
> > Retry-After header field if received."  The MUST requirement 
> > is likely too strong because of implications when included 
> > within a 503.  The MUST requirement is likely also too strong 
> > because of vulnerability to quit sending requests to that device 
> > for an extremely long time because attacker or bug caused the 
> > 503 to be sent containing Retry-After with an extremely
> > large value.
> 
> Perhaps you're right, but do you have suggestions for alternative
> wording?  Are you suggesting to replace "MUST" with "SHOULD"?

The current wording requires honoring the 503 with Retry-After overload mechanism.  RFC 3261 section 21.5.4 is at the SHOULD level instead of a MUST.  

If you only intended the Retry-After to apply to OPTIONS (instead of all requests), you can't use a 503 response (unless maybe you used an option-tag or something to indicate a meaning other than RFC 3261 section 21.5.4).

> I'm a little confused by your question. Are you asking whether 
> it applies to the target address to which the sender of the 
> OPTIONS sent the request or to the address from which the 
> recipient returned a 503, or the address of an intermediary?

I'm not referring to intermediaries; however yes to other parts of the question (although also asking if applies to more or both).  

I'm referring to devices with multiple ip-addresses such as 1 or more IPv4 addresses and/or 1 or more IPv6 addresses.  Thus the source ip-address of 503 response may be different from where UAC sent the OPTIONS; and the sender of 503 may have additional ip-addresses used for SIP communication between these two servers.  Since rfc3261 was somewhat vague, I'm attempting to ensure the draft is clear since it is requiring or recommending the use of 503 with Retry-After.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 10 Apr 2010 19:53:21 -0400

Hadriel,

Sorry for the belated reply.  I was on vacation this past week (and still
am), and wasn't able to respond to everything this week.

> I was worried about this too ('cause I also suggested option-tags and
> was worried about code-changes), but ISTM this is basically already the
> case: unless most folks do exactly what this doc says today, they're
> non-compliant and would require changing either code or config.

I don't know what percentage of devices would be compliant vs.
non-compliant.  However, unless we stick a stake in the ground somewhere, it
will continue to be rather messy.
 
> The thing is, afaict, many folks DON'T do what the doc says.  Not
> exactly, which is the same thing (right?).  For example, of three
> rather popular vendors I just looked at OPTION-ping traces of, none
> used the 486 for anything.  I don't know what they'd do if they got
> one.  All 3 of the vendors use 503 to signal "out-of-service" back, but
> at least 2 of them still allow (and want/expect to receive) in-dialog
> messages - I can't tell with the 3rd.  And one of them still _sent_ all
> messages even if it got a 503.

Note that in the language of the draft, I often use the word "should" for
things, including the 486.  We could mandate strict behavior in some cases
(and should), but "guidance" is all that is necessary in some instances.  If
a device wishes to keep responding until it drops deaf entirely, that's OK.
But, we ought to encourage the use of a different response code, in my
opinion.

In any case, the fact that OPTIONS is used for a "ping" so widely and there
are so many variations on the usage suggests we really need to reach some
agreement on something.  I'm certainly open to input, but we're not going to
be able to accommodate every implementation.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 10 Apr 2010 20:07:57 -0400

Brett,

> The current wording requires honoring the 503 with Retry-After overload
> mechanism.  RFC 3261 section 21.5.4 is at the SHOULD level instead of a
> MUST.
> 
> If you only intended the Retry-After to apply to OPTIONS (instead of
> all requests), you can't use a 503 response (unless maybe you used an
> option-tag or something to indicate a meaning other than RFC 3261
> section 21.5.4).

Ah, I think this was your point.  I believe a 503 would apply to the entire
server, just as 3261 says.  So, a device might return a 503 or 486.  In both
cases, the Retry-After header should be honored and these procedures do not
change the intent of 3261 -- at least not intentionally.

> I'm referring to devices with multiple ip-addresses such as 1 or more
> IPv4 addresses and/or 1 or more IPv6 addresses.  Thus the source ip-
> address of 503 response may be different from where UAC sent the
> OPTIONS; and the sender of 503 may have additional ip-addresses used
> for SIP communication between these two servers.  Since rfc3261 was
> somewhat vague, I'm attempting to ensure the draft is clear since it is
> requiring or recommending the use of 503 with Retry-After.

This is a problem general for SIP, since there is no way for a SIP entity to
know that a DNS query that returns 4 replies relates to the same or
different servers.  I can't fix that problem in this draft :-)

Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 14 Apr 2010 17:28:32 -0500

> different servers.  I can't fix that problem in this draft :-)

No, but in the 'normal' case, an INVITE is not directed to a RURI that
contains an IP address and port number, it's directed to a RURI with a
logical name for the 'service', and in that case, it's very logical for
Retry-After returned in the 503 to apply to the entire 'service'.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 15 Apr 2010 02:33:00 -0400

> Retry-After returned in the 503 to apply to the entire 'service'.

Messages are still transmitted to a certain server.  RFC 3261 provides
guidance as to when an entity should stop transmitting messages to a given
server. The OPTIONS ping draft does not change that logic.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 09:47:12 -0400

> server. The OPTIONS ping draft does not change that logic.

The 3261 language could be clearer on this subject.
In reality, messages are transmitted toward an address (typically an IP 
address), and arrive (if at all) at some server listening on that 
address. As you pointed out already, when the sender has a list of 
alternate addresses that it could have sent the request to, it has no 
way of knowing which ones are served by the same server.

So, in general I think the best the client can do is refrain from 
sending to the same *address*.

But maybe somebody else has better insight on this.

	Thanks,
	Paul