Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02

[Robert Sparks <[e-mail]>]

One more response to make sure we've wrapped the loose ends.

On 6/23/15 3:02 AM, Vincent Roca wrote:
> Hello Robert,
>
> I have merged the two emails.
>
>>>> I have several questions and suggestions WRT the *Security Section*.
>>>>
>>>> It is said that: « With this update, there may multiple subscribers 
>>>> to any given refer event state."
>>>> So what? What are the implications from a security point of view?
>>> Hmm. I wonder if sentence order made this less clear than it should 
>>> have been?
>>>
>>> The paragraph that sentence appears in discusses exactly what the 
>>> implications are - specifically that there is a new authorization 
>>> consideration.
>>> The paragraph that follow talks about how we deal with having that 
>>> new consideration.
>
> VR: Previous sentences of this paragraph explain that the 
> authorization for a SUBSCRIBE is now decoupled from
> the REFER mechanism. And then, the last sentence mentions the 
> possibility of having **multiple** subscribers
> which is not discussed previously, hence my remark. I don’t think it’s 
> a matter of sentence order. And the paragraph
> that follows does not mention nor discuss explicitly this idea of 
> **multiple** subscribers. I don’t know if this notion
> of **multiple** subscribers is difficult to handle or not, if it 
> creates risks or not. Can you clarify the text?
Ah - multiple subscriptions in SIP events is _normal_. This sentence is 
here because an unextended REFER request could
only create one subscription. It's a reminder to the implementer that 
all the normal SIP events behavior comes into play
when you use this extension. There are no extra considerations to 
discuss beyond the authorization one already called out.
>
>>>> IMHO, the third paragraph does not make an appropriate use of the 
>>>> normative vocabulary.
>>>> For instance, it is said:
>>>> "the URI should be constructed so that it is not easy to guess, and 
>>>> should be protected against eavesdroppers"
>>>> Shouldn’t the author use « SHOULD » on both occasions?
>>>> The following sentence is ambiguous. It says:
>>>> "For instance, SIP messages containing this URI SHOULD be sent 
>>>> using TLS or DTLS..."
>>>> "SHOULD" and "For instance" are contradictory. I suggest removing 
>>>> "For instance".
>>>> Similarly, next sentence says: "can redirect". I think "SHOULD" 
>>>> redirect is more appropriate.
>>>> Finally the same remark (i.e. use « SHOULD") can be done for the 
>>>> next two sentences about additional authorization
>>>> mechanisms.
>>> Ben made a similar comment. The first 2119 requirement you point to 
>>> needs to move up into the protocol definition part of the document.
>>> The second is restating text that’s in RFC3261, and we don't need to 
>>> repeat the 2119 here - I'll clarify the language to say "use the 
>>> mechanisms the base specification provides".
>
> VR: IMHO repeating normative vocabulary is not an issue as long as it 
> is used homogeneously in the whole document,
> whereas the opposite would be an issue.
>
>>>> In the 4th paragraph, it is not clear to me why it is said that 
>>>> there is « a factor of 11 amplification due to retransmissions
>>>> of the request ». What are the foundations for this « 11 » factor?
>>> This is base SIP behavior. The non-INVITE transaction state machine 
>>> retransmits 11 times before giving up if something on the other end 
>>> doesn't talk back
>>> (which is what will happen if the other endpoint is not SIP aware).
>
> VR: okay, I see. I’ll let you judge whether it’s appropriate or not to 
> justify this figure in the document.
>
>>>> And what happens if the victim is SIP aware?
>>> It will send an appropriate response, so there won't be the 
>>> retransmissions of the request. In other words, sending this as raw 
>>> traffic towards a sip aware element is no different than sending any 
>>> other sip request towards a sip aware element.
>
> VR: okay. Same remark as above.
>
>
>>> Additionally, I have concerns about *backward compatibility*.
>>> The mechanisms introduced by this extension may not be backward 
>>> compatible with RFC 3515 (see section 7).
>>> However I don’t see any discussion in the current document.
>>> There are some guidelines in RFC 6656 (8.3.1) concerning the 202 
>>> response code, but what is described in the first
>>> paragraph is new to this document.
>> Our AD already noted that the second paragraph should actually be 
>> removed from this document - it is covered in refer-clarifications.
>
> VR: ok
>
>> For the first paragraph - backwards compatibility is ensured by the 
>> base SIP extension mechanism.
>> An implementation of 3515 that is not aware of this extension (and 
>> the update to 3515 established by this document) would reject any 
>> requests that tried to invoke the extension (if either of the tokens 
>> defined here appeared in a Require: header field, that implementation 
>> would reject them with a 420 response.
>
> VR: ok, I understand. But is « MAY accept » the appropriate? I don’t 
> think so. What about:
>
> NEW:
>    The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog
>    SUBSCRIBE requests to event 'refer' is removed.  An element MUST
> process a SUBSCRIBE request to event ‘refer', following the
>    requirements and guidance in this document,since REFER is no longer the
>    only mechanism that can create a subscription to event ‘refer’.
No, MAY is the appropriate word here. An element could have many reasons 
to not accept the request, and accepting is what we need to talk about 
at this point.
The rest of the draft details what is required once that choice to 
accept has been made.

Thanks for your review work on this!

RjS
> Cheers,
>
>    Vincent
>