[Sip] Comments/nits on draft-ietf-sip-referredby-01

["Mary Barnes" <[e-mail]>]

Hi Robert,

Based on the action I took in San Francisco, I've recently reviewed the
draft and have the following comments. Some are just editorial nits, others
relate to the discussion in San Francisco (and likely you're already
planning these changes) and a few new items for discussion.  

Editorial Nits:
-------------------
- Abstract:  third sentence: I would propose to reword this and change the
word "reference" to "referenced request"  (it may be just me but I had to
read that several times to convince myself that it said what it should have;
or perhaps you could write the word "reference" as "REFER-ence")

- Section 7.3, second sentence: "choses" -> "chooses" or "chose"

- References: identity, authid-body and cc-transfer need upversioning.

Per discussion in San Francisco:
------------------------------------------------
- Section 4: Call-ID should not be used for the token, thus the open issue
in section 4 & 9 (Issue 2)  is closed, with the 2nd paragraph to be updated
appropriately.  Per the discussion, the most recent Authid-body draft
addresses the REFER as a special case where the Call-ID cannot be used. 

- Section 4.1: 3rd paragraph suggesting that the target verify the identity
in the FROM in the token matches the SubjectAltName from the signing
certificate.  As I recall, it was highlighted during the discussion that the
referrer may not have a certifcate matching that field, thus I think it was
ageed to remove that (but my detailed notes are not conclusive, nor are
those on the SIP webpage).  Thus, the first Open Issue in that section is
closed. This is also listed as Issue 3 in section 9 and I think the
conclusion is that the Referred-by should be the identity reflected in the
Token. 

-Section 4.1: 2nd issue (also listed as Issue 4 in section 9) around
restricting the referree to use the To value from the original dialog as the
From.  There was no conclusion around this issue and I really think you
don't want to do that. I think you could actually use History-Info (for the
Referrer to indicate it's identity).  Refers are identified as a form of
retargeting in the requirements document. Although, I don't think the
current normative text in the solution draft fully takes this into account,
but it should.  Thus, if you have the security around History-Info, then you
can be certain that the referrer did send that refer to this particular
referee (per your Issue 1 in section 9). 

Other items:
--------------------------------------
- Section 2.1: Propose to add a final paragraph (or another sentence to the
current final paragraph) similar to the following to this section to
indicate what the Referrer should do upon receipt of a 429:
"Upon receipt of a 429 response, if the Referrer still wishes to REFER to
the target, a Referred-by token MUST be included in the referenced request."

- Section 2.3: Last paragraph: should this be a MUST (reject an otherwise
well-formed request with an invalid token)?   Reasonably, one should, but
perhaps there are users that would still like to be able to decide
themselves, thus I would suggest this be stated similar to the previous
paragraph as:

"The refer target SHOULD reject an otherwise well-formed request with an
invalid Referred-By token (see Section 4) with a 429 error response. If the
agent chooses to proceed with the request and provides any information from
the Referred-By header to its user as part of processing the request, it
MUST notify the user that the information was determined to be invalid." 

My reasoning is that it just seems that if an optional parm is mucked up (in
general or from a security perspective), then following the adage of being
generous in what you accept ...that whether to accept the request, provided
that it is warned that it's bad,  should still be up to the user.  This also
seems consistent with the MAYs in the previous 2 paragraphs. I do understand
the reasoning that you'd want to let the Referrer know and that by allowing
the request, you're actually bypassing the security put in place to keep the
bad guys from mucking with the messages, but again since it's optional, it
just seems that you can't make it stronger than a SHOULD. 

- Section 4.1:  2nd paragraph suggesting that "A target SHOULD verify the
request...".  I don't think this is useful since retargeting makes this
check not meaningful.  UNLESS, of course, you're using History-Info.  With
History-Info, you could verify that the Refer-To matches one of the
Targeted-to-URIs (and of course, this implies that this information has all
been sent securely, not mucked with by the proxies, etc.).  

Regards,
Mary H. Barnes
[e-mail]
972-684-5432

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip