Skip to main content

Last Call Review of draft-ietf-sipcore-refer-explicit-subscription-02

Request Review of draft-ietf-sipcore-refer-explicit-subscription
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-23
Requested 2015-06-05
Authors Robert Sparks
Draft last updated 2015-06-25
Completed reviews Genart Last Call review of -02 by Vijay K. Gurbani (diff)
Genart Telechat review of -02 by Vijay K. Gurbani (diff)
Secdir Last Call review of -02 by Vincent Roca (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-sipcore-refer-explicit-subscription-02-secdir-lc-roca-2015-06-25
Reviewed revision 02 (document currently at 03)
Result Has Issues
Completed 2015-06-25

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

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

"SHOULD" and "For instance" are contradictory. I suggest removing "For

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


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






 Message signed with OpenPGP using GPGMail