Re: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT)

[Eric Burger <[e-mail]>]

> On Jun 11, 2019, at 8:58 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
[snip]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Do we want to give any references/examples for "some jurisdictions" or
> "many jurisdictions”?

I would prefer not to put it into an archival document. One might think the U.S. and Canada would be examples, but I cannot speak on behalf of the U.S. Government, Canadian Government, or any governmental department, agency, or commission.

[snip]
> Section 3.2.2
> 
>   The payload contains two JSON values.  The first JSON Web Token (JWT)
>   claim that MUST be present is the iat (issued at) claim [RFC7519].
>   The "iat" MUST be set to the date and time of the issuance of the 608
>   response.  This mandatory component protects the response from replay
>   attacks.
> 
> nit(?): Perhaps this protection is only "outside the scope of a narrow
> window of time corresponding to the allowed RTT and any permitted time
> skew", per Section 3.3.

Given the ubiquity of using iat for just this purpose, I would offer it would be redundant to reiterate it here. Would it be OK with you to not go there here?

>                                      Call originators (at the UAC) can
>   use the information returned by the jCard to contact the intermediary
>   that rejected the call to appeal the intermediary's blocking of the
>   call attempt.  What the intermediary does if the blocked caller
>   contacts the intermediary is outside the scope of this document.
> 
> It seems like it is permissible for the intermediary to reject this new
> call as well; can we get into some sort of recursion-like situation?

That would be a major fail on the part of the intermediary. However, I do not think there is anything we can do about it. We certainly do not want to tell the intermediary operator they cannot protect themselves from, in this case, a TDoS attack. On the other hand, I do not think we can possibly require the intermediary operator to accept the call. That would be some magic Protocol Policing(tm) if we could! Because of the risks, I am not sure we even want to give guidance - such an operational issue seems outside the scope of the IETF. However, if the IESG or SIPCORE folks think otherwise, I can put in some language to that effect.

[snip]
I edited most all of your other comments in. Thanks!