Last Call Review of draft-ietf-sipcore-rejected-08
review-ietf-sipcore-rejected-08-secdir-lc-cam-winget-2019-07-02-00

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