Re: [sipcore] Secdir last call review of draft-ietf-sipcore-multiple-reasons-01

[Joseph Salowey <[e-mail]>]

Hi Robert,

Thanks for your response.  It sounds like this should be a source of many
implementation issues.

Cheers,

Joe

On Thu, Sep 29, 2022 at 3:33 PM Robert Sparks <[e-mail]> wrote:

>
> On 9/29/22 3:46 PM, Joseph Salowey via Datatracker wrote:
> > Reviewer: Joseph Salowey
> > Review result: Ready
> >
> > 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.
> >
> > The summary of the review is Ready
> >
> > I have one question.  The document takes a field that previously held one
> > reason and allows to hold multiple reasons. Since this behavior is only
> allowed
> > for protocols that define multiple reasons, it seems the exposure to
> existing
> > implementations would be small, however it's possible that this behavior
> will
> > leak
> leak?
> > into some existing cases. Do we have any implementation experience as to
> > what existing implementations will do if the receive multiple reasons
> that they
> > do not expect?
>
> We tested having multiple values appear where they shouldn't in the
> reason headers for the SIP protocol and IIRC Q.850 (be careful - I mean
> "speaking about SIP in the reason header" as _all_ of this is carried in
> the SIP protocol) at several SIPits (quite some time ago) and
> implementations present did the right thing.
>
> For multiple reasons to start being expressed for one of the protocols
> already defined, there would have to be a series of implementation errors.
>
> If by leak, you mean "a message with a new protocol value that allows
> (and has) multiple Reason header field values lands on an older
> implementation that doesn't understand reason headers with that new
> protocol", then yes, we also tested sending unknown protocols in Reason
> and existing implementations mostly ignored them as RFC3326 suggests.
> The exception were some implementations that would _remove_ them when
> forwarding, acting in ways that our standards don't define. There will
> be plenty of motivation (see what STIR is using this for) to be sure
> such implementations do the right thing with multiple reason headers for
> defined protocols going forward.
>
> >
> > Thanks,
> >
> > Joe
> >
> >
>