Reviewer: Nancy Cam-Winget Review result: Has Nits 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..."
