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

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Tue, 02 February 2016 21:34 UTC

Return-Path: <pgiralt@cisco.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 877231B2F2B for <insipid@ietfa.amsl.com>; Tue, 2 Feb 2016 13:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 udgNvrlwlx8E for <insipid@ietfa.amsl.com>; Tue, 2 Feb 2016 13:34:03 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A321B2B0B for <insipid@ietf.org>; Tue, 2 Feb 2016 13:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6916; q=dns/txt; s=iport; t=1454448843; x=1455658443; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BN8RfC57IzqF2/YzhB4o6/btBxh319EP6z9BInrcP6I=; b=NjXOUUCW1PFxgdifkpjNhTHGXOyr90b6C9TStUH3sbeX67TY+1VSIqLm 1xRZHsVK9MrPLl1KPkRDt3qz21r5Sz+x4NF0z/f56ALevmqJCBKIYY6S6 esM+A6zR2fImzcvICa2fgYtKMnpgE4SMBv2Pu2xX+dEORIb6Eu0P+73A/ A=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAgCAILFW/49dJa1egzqBPwaIU7FuDoFkhg0CgUw4FAEBAQEBAQGBCoRBAQEBAwEjTwcFCwIBCBgqAgIyJQEBBA4FDogFCLBPjm0BAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYPgW2BT3uHMiuBDwWHSQcNhneIHQGCeYFjiG6BW40WhW+EfoNRAR4BQ4IDGYFIaogyBCAZfAEBAQ
X-IronPort-AV: E=Sophos;i="5.22,386,1449532800"; d="asc'?scan'208";a="233370462"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2016 21:33:45 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u12LXjZI031971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 21:33:45 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 16:33:44 -0500
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 16:33:44 -0500
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Brett Tate <brett@broadsoft.com>
Thread-Topic: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
Thread-Index: AdFH4a6/NsdUhMmHTreHxlK6Kbew9gATyd0AAC+eWAAFTv7GAA==
Date: Tue, 02 Feb 2016 21:33:44 +0000
Message-ID: <D16022E4-2AD3-4A58-A385-6BE2779D29CA@cisco.com>
References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com> <dfc2855f2eea74c13d5efb3e6ddf01ff@mail.gmail.com>
In-Reply-To: <dfc2855f2eea74c13d5efb3e6ddf01ff@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.96.60]
Content-Type: multipart/signed; boundary="Apple-Mail=_266A023C-797B-4BC8-A656-AA0C5DB04C5A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/9h4gegEw8zYaniUXGFnXDEGLlnU>
Cc: "insipid@ietf.org" <insipid@ietf.org>
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: Tue, 02 Feb 2016 21:34:05 -0000

Brett,

After thinking through this a bit more, reverting to the previous UUID if a mid-dialog transaction fails on both endpoints and intermediaries is the cleanest approach to solve this issue and should address your concerns. The text will make it clear what needs to happen in all scenarios and will ensure RFC 3261 Section 8.2 is not violated. I will be updating the draft with these changes and starting a new thread for comments. As always, thanks for the feedback.

-Paul


> On Jan 6, 2016, at 4:01 PM, Brett Tate <brett@broadsoft.com> wrote:
> 
> 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.