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 <rjsparks@xxxxxxxxxxx> 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
>
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
