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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jun 19, 2019 at 10:50:40PM -0400, Eric Burger wrote:
> 
> 
> > 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.

Understood.

> [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?

That would be okay, yes.

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

Mostly I just wanted to check that I was understanding things properly;
I agree that would be a major fail by the intermediary.  So please don't
add any guidance solely on my account!

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

Thanks!

-Ben