SECDIR review of draft-ietf-sipcore-rejected-08

Reviewer: Nancy Cam-Winget
Review result: Ready with Nits

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.


This document defines the use of value 608 as the "rejected" SIP response code. More specifically, the intent is to define a code such that an intermediary (e.g. an analytics engine versus the target user server) can signal that it is rejecting the call.

The following are general comments and suggestions (and editorial nits at the end):

3.1 "Proxies need to be mindful that a downstream intermediary may reject....", this seems  too imply that there are other nodes in the path that can generate the 608 reject.  What is the underlying key used to sign the JWT and how can this be validated as being a proper and identifiably authorized intermediary to issue such a 608 signal?  What happens if multiple intermediaries want to reject the call? Perhaps adding a sentence here would be helpful.

6. "Yet another risk is a malicious intermediary.....strongly recommend the recipient validates to whom they are communicating"; it seems like perhaps this should be a MUST in that the recipient should validate that both the message is valid but also the sender can be trusted. Signing the jCard is actually a MUST.
This paragraph is a bit long and hard to discern, it could benefit from breaking it into the different considerations: the need to at minimum sign the jCard, the need to also trust (verify the authorization or validity of the source).
  - there should also be considerations or how to handle multiple intermediaries sending the sip.608 signals




Editorial nits:

- I presume the [RFCXXXX] refers to this draft once it is RFC'ed....

3.4 "The simple rule is a network element ....", this should be a stronger MUST that is the network element that is sip.608 "MUST convey at a minimum..."