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

[Robert Sparks <[e-mail]>]

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