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

From: Vincent Roca <[email-masked]>
Date: Mon, 22 Jun 2015 15:37:36 +0200

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: almost ready

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?

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.

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? And what happens if the victim is SIP aware?

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.

Typo, section 8: « be » is missing in the following sentence:
	« With this update, there may multiple subscribers to any given refer event state."

Cheers,

   Vincent

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Jun 2015 10:34:47 -0500

Thanks Vincent -

Responses inline:

On 6/22/15 8:37 AM, Vincent Roca wrote:
> *Summary: almost ready*
> I have several questions and suggestions WRT the *Security Section*.
>
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.

> "the URI should be constructed so that it is not easy to guess, and 
> should be protected against eavesdroppers"
> 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".

>
>
> 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).
> 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.
>
>
>
> Additionally, I have concerns about *backward compatibility*.
> The mechanisms introduced by this extension may not be backward 
> compatible with RFC 3515 (see section 7).
> There are some guidelines in RFC 6656 (8.3.1) concerning the 202 
> response code, but what is described in the first

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Jun 2015 10:43:36 -0500

(I hit send too soon - the rest of the responses are inline)

> what happens if the victim is SIP aware?
starting here - see the previous response for everything above.
> 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.

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.
> « With this update, there may multiple subscribers to any given refer 
ack.
>
>
> Cheers,
>
>    Vincent
>
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Vincent Roca <[email-masked]>
Date: Tue, 23 Jun 2015 10:02:42 +0200

Hello Robert,

I have merged the two emails.

>> 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?

>> 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.

>> 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

VR: okay, I see. I’ll let you judge whether it’s appropriate or not to justify this figure in the document.

>> 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.

> 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’.

Cheers,

   Vincent

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 23 Jun 2015 09:33:07 -0500

On 23 Jun 2015, at 3:02, Vincent Roca wrote:

>>> 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 
> VR: IMHO repeating normative vocabulary is not an issue as long as it 
> is used homogeneously in the whole document,

While this is small enough to not matter either way, in general I prefer 
not to have multiple occurrences of the same normative statement, unless 
one clearly refers to the other. Even if they are in sync, it can cause 
confusion for people trying to reference authoritative text, and an 
opportunity for error in future updates.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 24 Jun 2015 08:08:19 +0200

Hello Ben,

I do understand that such a practice across different documents is dangerous.
But this is not what I’ve been doing so far within a single document. I’ll think about
it in the future.
Thanks,

  Vincent

> Le 23 juin 2015 à 16:33, Ben Campbell <[email-masked]> a écrit :
> 
> While this is small enough to not matter either way, in general I prefer not to have multiple occurrences of the same normative statement, unless one clearly refers to the other. Even if they are in sync, it can cause confusion for people trying to reference authoritative text, and an opportunity for error in future updates.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Jun 2015 14:17:40 -0500

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

On 6/23/15 3:02 AM, Vincent Roca wrote:
> 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.
>>>> Finally the same remark (i.e. use « SHOULD") can be done for the 
>>>> next two sentences about additional authorization
>>>> mechanisms.
>>> The second is restating text that’s in RFC3261, and we don't need to 
>>>> 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
>> 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.
>
>    requirements and guidance in this document,since REFER is no longer the
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