Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

Brett Tate <brett@broadsoft.com> Wed, 06 January 2016 21:01 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E21A06E9 for <insipid@ietfa.amsl.com>; Wed, 6 Jan 2016 13:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB5isoDmR-t5 for <insipid@ietfa.amsl.com>; Wed, 6 Jan 2016 13:01:27 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C021A065C for <insipid@ietf.org>; Wed, 6 Jan 2016 13:01:26 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id b14so93752078wmb.1 for <insipid@ietf.org>; Wed, 06 Jan 2016 13:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=5ivPWAoAJpUtuNxOEXQ4fTPflHXEq0xR3jHHdFSfnfE=; b=nI/Q9f44o1rDSFZ7BhWWdDPtkH6l2CEBKWTh8w1vVMo3fEoqcRVnxxrUj4Xx4ji9y7 Ha/ogPRL/Igwxt1fcJwMKechC4+xJxBeiQ/y2If2V3BGFB8o9etJSCbjQqRnGepapxSw WcQVpKUqbnEirXOt5Z0KHq2Znu89bwdAK/hM/nFh8agRZ0ue8cJzdsWaAlJXTKqoItWS FhFRzvXf4yU+1no4kH4RnnVg40DJ8t6Z84BPZbMptZKahIVWLkvj99d/+xXrRTiDVmvp wRPv7Gai1gi8fakQDO5slFChVEGGiJbtvRqn12lZhCNcVrrzxFk1ytCOvQOXgrMfIGaQ V0Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=5ivPWAoAJpUtuNxOEXQ4fTPflHXEq0xR3jHHdFSfnfE=; b=Xzw/x3RRJpzI3MrXPGcesMLZHBWKaofu9iNv1CJGnGwyDQfCojj3eEQ8KVcEoPphDy IdE22MkVT78EfJwYsu+3zRE63erjS2WycNGPtmv/AKurCVDGHVa96Ew/HlKGtjCMLOuG IK7JQMzl8HHeHL8m8A+VE7P2J9FIow/AfQ+Wdc8gciou4OGDJtRHhMUSzBTNHLxIUtTg II7BIOpSyEkX29QyuVJABdvaEDga4ZNZod/gDlVr+ah9G1i0Turpqv+ji1qbrcSLNYal Fzj8VXWHnlV3cPV+Men6oH+SDP/zRnyj3pA2tETRxzuHv0cyHG9D0cw07SNTwn83QZ4j 9KEw==
X-Gm-Message-State: ALoCoQniMtBkVuKFSujPBhHn1efbpF2iCL6ZZEXDRtPox1IBymiEXGQB8WqP0vXJ7P6oJbGJHkaOMoCQTjEaZlfM6tHbDoiOpJMl7eXy8coQXc5vtA96sds=
X-Received: by 10.28.30.210 with SMTP id e201mr13055766wme.42.1452114085212; Wed, 06 Jan 2016 13:01:25 -0800 (PST)
From: Brett Tate <brett@broadsoft.com>
References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com>
In-Reply-To: <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFnDhLYfVMGF0bwk7F0rd0uXRgsJwHGzYd+n7TY9OA=
Date: Wed, 06 Jan 2016 16:01:24 -0500
Message-ID: <dfc2855f2eea74c13d5efb3e6ddf01ff@mail.gmail.com>
To: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/g09lNWZebLELi1_f6yfXvm_QTl8>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2016 21:01:29 -0000

Hi,

Thanks for the response; reply is inline.


> > The proposal currently appears to violate (or alter)
> > RFC 3261 section 8.2: "If it is rejected, all state
> > changes MUST NOT be performed".  Similarly it also
> > appears to impact the following RFC 6141 section 3.3
> > SHOULD: "If any of the changes requested in a re-INVITE
> > or in any transaction within it have already been
> > executed, the UAS SHOULD return a 2xx response”.
>
> You could argue that the intermediary is not the one
> actually rejecting the request bur merely relaying the
> rejection. The proposal says that the device that is
> actually doing the rejection of the request is not storing
> the UUID.  For troubleshooting purposes, which is the
> desired objective of the Session-ID, it makes sense to
> do as I proposed.

The argument is weak.  You are basically saying that an intermediary should
remember the changed uuid even though the re-INVITE to connect a different
session failed.

The proposal appears to cause intermediaries (e.g. B2BUAs) to violate RFC
3261 section 8.2.  Similarly it also appears to impact the following RFC
6141 section 3.3 SHOULD: "If any of the changes requested in a re-INVITE or
in any transaction within it have already been executed, the UAS SHOULD
return a 2xx response”.


> > You might want to exclude CANCEL and its 2xx response
> > from the algorithm (although decision might be
> > influenced by decision concerning 100 response).
> > CANCEL and related 2xx response are not end-to-end (even
> > if using proxies instead of B2BUAs).
>
> Is there any situation where including CANCEL could cause
> a problem?

It depends upon what you mean by problem.  It can cause more inconsistencies
because of race conditions and not being end-to-end.  I'm not sure how
vendors typically handle CANCEL in relation to RFC 3261 section 8.2's "all
state changes MUST NOT be performed" if the CANCEL causes a 487 for
re-INVITE; however based upon RFC 6141, it looks like the CANCEL changes (if
anyone actually allows them) should be undone when sending the 487 response
similar to what it mentions concerning UPDATE.  Similarly depending upon how
long the transaction being cancelled is remembered, the CANCEL might be
received after final response is sent and still result in 200 response for
CANCEL.


> >> The only additional rule for stateful intermediaries
> >> is that if they accept a request and then forward that
> >> request to another destination (therefore there was no
> >> error found with the message), this will also trigger
> >> the intermediary to update the retained UUID.
> >
> > The proposal means that not all of the devices will
> > necessarily agree if a uuid changed during failure
> > situation.
> >
> > Concerning "therefore there was no error found" statement,
> > be aware that forwarding a request does not necessarily mean
> > that no error was found (i.e. device can be lenient) or that
> > the request won't eventually be rejected (with 400 or other
> > failure response).
>
> Yes, I totally understand that the request might be eventually
> rejected by some other device down the line, but as an
> intermediary, it seems like this is the best we can do.

No comment since currently unsure if the proposal is better than the draft
or other potential mechanisms.


> >> There will always be feature interactions that result in
> >> temporarily mismatched Session IDs when intermediaries are
> >> involved, but I don’t think the above proposal makes this
> >> any worse of a problem in real-world applications.
> >
> > I'm currently not sure if the proposal is better or worse
> > than draft version 16.
> >
> > From the rejecting device perspective, the proposal appears
> > to be better.  The proposal currently appears to leave partial
> > changes up to rejecting device (i.e. intermediaries allowed
> > change but rejecting device did not) without any indication
> > to modifier to know if change was successful at the remote
> > endpoint.  This is about the same as changing some of the MUST
> > to SHOULD (or MAY) within the current draft which would allow
> > the rejecting device to make the decision concerning which is
> > better for the situation.
> >
>
> Changing MUSTs to SHOULDs would certainly address many of these
> issues as well, but leave us with the issues you pointed out
> with RFC 3261 section 8.2.

Yes; however the proposal also violates RFC 3261 section 8.2 since not
always rolling back (on the intermediaries) or after 101-199 (on the
rejecter).  And not allowing the first rejecter to potentially also violate
it within the specific situation mandates inconsistency concerning the uuid
values.