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
