Re: [Insipid] draft-ietf-insipid-session-id-10: comments

Brett Tate <> Tue, 10 February 2015 15:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED91E1A9037 for <>; Tue, 10 Feb 2015 07:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jkGbdGVBf2U2 for <>; Tue, 10 Feb 2015 07:01:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B347B1A903E for <>; Tue, 10 Feb 2015 07:01:00 -0800 (PST)
Received: by with SMTP id c9so28912798qcz.6 for <>; Tue, 10 Feb 2015 07:01:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=VfXJGFJz8Q9QXmgzY4KeW5DF0l/cmDK2sb8tcz8xe2c=; b=G7RP3YyWdi/TZf0k51CWIinj4ABl0b5E5/Ow16B7TU+8BOMfGBHiaNbsAH7HeTFfrI enfNk13XSqy7+RQgmUoO/pO2+124GVbUVDl2Y7+hyMorR+rQjW0O62iySNlK1iuakR4l L2xMXCDR9ymEMfBN9WfdEo0oQuFFP3ppdgFEhAoA3tHUuCeN01zExFK/dQx94O8uKLQE 3WOhrvncPtYbQ+KOajtp4fSGLUIvVafIjIbLEhoAMjIS9uzE2cnPAdCBk1d1BbfacI2T sk/AGc2P1ekoyMa3nMvq7P+WCsEhXnq3CxYuE4emdkSg+0Yo4gLQxzXtdYAFkySqXOFg s9ow==
X-Gm-Message-State: ALoCoQnyYo+bl6SLWUt7uq8EbMS5vKJ0+kce9V5VYPZWThk0LUHdNRxBtlzCe5wsYx8L4cheagQN
X-Received: by with SMTP id p16mr38918048qak.84.1423580460007; Tue, 10 Feb 2015 07:01:00 -0800 (PST)
From: Brett Tate <>
References: <> <em27215242-e45e-4ee5-bbca-62c35f65d8f2@helsinki>
In-Reply-To: <em27215242-e45e-4ee5-bbca-62c35f65d8f2@helsinki>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKJypjO4fCSNSfydgH5vt5grh/60Jt2wOwA
Date: Tue, 10 Feb 2015 10:00:59 -0500
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Feb 2015 15:01:52 -0000


Thanks for the response; reply is inline.

> OK, how about these as the first two paragraphs?


> Note I changed a MAY in your document to "might".  I don't
> want to suggest that it's permissible, but noting that it
> might happen is acceptable.

If it is not permissible, then intermediaries which generate (instead of
only relay) requests and responses must track the Session-ID.  You can
remove my suggested paragraph since I only proposed it because you indicated
"We do not want intermediaries really getting involved in the exchange of
UUID values".

Consider the following race condition where the UPDATEs cross between A and
the proxy.  If the proxy generates a 407, SHOULD/MUST it indicate {C,A},
{B,A}, or something else?  What draft snippet supports your answer?

A   proxy

-->  UPDATE {A,B}
<-- UPDATE {C,A}
<-- 407 {?,A}

Do you think intermediaries which generate (instead of relay) requests such
as BYE SHOULD/MAY/MUST track the Session-ID UUIDs so that the BYE could
contain the same UUIDs within the Session-ID?  If so, where is it mentioned
within the draft.

> >>  If an intermediary is responding on behalf of an endpoint,
> >>  then what the text currently says that "if it knows" the
> >>  UUID value of the opposite endpoint, includes it. Otherwise,
> >>  it either uses the NULL value or fabricates a value.
> >
> >What section and paragraph says that?
> That's in Section 7.  Just to avoid mismatch in paragraph count, the
> text is:
> ====
> When an intermediary transmits a provisional response or a response to a
> CANCEL request, the “remote-uuid” field will contain the UUID value of
> the UA that sent the message that prompted the transmission of the
> response. When the UUID of the destination UA for the message that
> prompted the transmission of the response is known, the intermediary
> MUST insert the UUID of the destination UA in the “local-uuid” field of
> the response. Otherwise, the intermediary MAY set the “local-uuid” field
> of the response to a locally generated UUID value or the null UUID
> value.
> ====
> Note that the bit about CANCEL is new and added per our discussion.  The
> word "provisional" was removed from the original text, also, to account
> for the CANCEL response.

Same comment as last time, I don't think that it is adequate.  It looks like
the paragraph only applies to CANCEL responses and provisional responses.
What about all of the other requests and responses that an intermediate can

> The section in intermediaries started out by limiting when they were
> allowed to touch messages.  The intent was to strictly reduce
> opportunity to do damage, while being mindful that some will.

Damage?  Because of all the potential race conditions, the draft provides no
means to ensure that an endpoint knows the correct remote-uuid.

If A receives the following at about the same time, does A "know" that the
remote-uuid is B or C?  A can only assume that they were sent in the order

200 response with {B,A}
UPDATE with {C,A}

> The one piece of text that is missing is a statement that says something
> like this as a final paragraph in section 7:
> ====
> Having said the foregoing, intermediaries that manipulate messages
> containing Session-ID header values should be aware of what values were
> last received by an endpoint and, following any kind of service
> interaction initiated or affected by the intermediary, of what values
> the receiving endpoint should have knowledge to ensure that both
> endpoints in the session have the correct and same values.  If an
> intermediary can determine that an endpoint might not have received a
> current, correct Session-ID header value, the Intermediary SHOULD
> attempt to provide the correct Session-ID header value to the endpoint
> such as by sending a re-INVITE message.
> ====
> How does that sound?

I guess that you changed your mind about if an intermediary should ever send
a request solely to update the Session-ID.