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

Robert Sparks <> Thu, 29 September 2022 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8222C14CF1C; Thu, 29 Sep 2022 15:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C1UU3knFmO4h; Thu, 29 Sep 2022 15:33:29 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 43C53C14CF1B; Thu, 29 Sep 2022 15:33:29 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.17.1/8.17.1) with ESMTPSA id 28TMXQWm005017 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 29 Sep 2022 17:33:27 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1664490807; bh=KyYPwnfnoLT0Xi6QizhJDx5baQFyw1YD2b0BjuiEb4o=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=X9xLjZo655Cg/pB4P7XGcjF2RBRxDbRIRwE2O3INMje168k4wRNvkutV9vTOK5uvg 14BVAOxp9reVb76eUnW6YAlQlixiy4g+OumneC5I87wAsOg6sYv39l4bu75oJfg2PU WXf4Q46D/gjQ2HAqIFlOCM78TTbsfBtARf0buOp4=
X-Authentication-Warning: Host [] claimed to be []
Message-ID: <>
Date: Thu, 29 Sep 2022 17:33:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: Joseph Salowey <>,
References: <>
From: Robert Sparks <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-sipcore-multiple-reasons-01
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Sep 2022 22:33:33 -0000

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