IETF Logo Mail Archive

Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323

"Paul Giralt (pgiralt)" <pgiralt@cisco.com> Wed, 29 June 2016 20:11 UTC

Return-Path: <pgiralt@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBEA12D684 for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 bDWvc62V9qmL for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 13:11:17 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C62112B03D for <insipid@ietf.org>; Wed, 29 Jun 2016 13:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3378; q=dns/txt; s=iport; t=1467231058; x=1468440658; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=InFNALGlIWCxd5dfI+w5a+tafYjljMYaIEcJADoQctY=; b=JYq3864WciEHrGwRK1IvdI25xlX0vXeOu0g9oniUf8ppApka0nnHo9wS jh8W2mRQeaaPvN0tNrEMJsV4/DNF8peaI8fjXdJpixNUDnk9oz7ybc2/C RlpG+njWhmPqf+HuikCEoCyuKBA3w1woLQWhcTDZrnL1qNjct+w2qhBYg 0=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D5AQDnKnRX/5tdJa1bgz6BUwa5RIF7hhgCgTI4FAEBAQEBAQFlJ4RMAQEBAwEjRREFCwIBCBgqAgIyJQEBBA4FDogaCLN4kBYBAQEBAQEBAQEBAQEBAQEBAQEBAQEODoYogXcIgk6BOYYIK4IvBZkFAYMtgWyJJI8lkAIBHjaCAxKBW26ISX8BAQE
X-IronPort-AV: E=Sophos;i="5.26,548,1459814400"; d="asc'?scan'208";a="120443179"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 20:10:57 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5TKAvWP004785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 20:10:57 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 16:10:56 -0400
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.1210.000; Wed, 29 Jun 2016 16:10:56 -0400
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
To: Brett Tate <brett@broadsoft.com>
Thread-Topic: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
Thread-Index: AdHRa3mN5MulHSFWQ++NJW6ws0igKAAX+N8AACVNQwAAANMmgA==
Date: Wed, 29 Jun 2016 20:10:56 +0000
Message-ID: <0FD350E3-5964-44CC-A0B4-A894219757C4@cisco.com>
References: <21575ee6e889d5d4fdd306e7ca579185@mail.gmail.com> <D98EFE31-60FF-4038-8D81-36572B4A39CF@cisco.com> <fe19523ad1cfdc0d74894e5ac2902753@mail.gmail.com>
In-Reply-To: <fe19523ad1cfdc0d74894e5ac2902753@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=_95E142D8-B1A9-4A11-8046-74B044AD77A6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/YnFaG4JUWbCbg8N8_ZAsn77ZOiA>
Cc: "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Jun 2016 20:11:19 -0000

Thanks Brett. Let me see if perhaps I can add a mention in the Security and Privacy considerations section. As usual thanks for your insight and feedback.

-Paul

> On Jun 29, 2016, at 3:47 PM, Brett Tate <brett@broadsoft.com> wrote:
> 
> Hi,
> 
> Thanks for the response; reply is inline.
> 
>> Could it be considered “essential” for troubleshooting?
>> Maybe not because you could troubleshoot without it - it
>> would just be more difficult - but it is not absolutely
>> necessary (essential). However, a customer may have some
>> diagnostic infrastructure in place that relies on the
>> presence of the Session-ID header in which case then
>> it is essential for their tools to work.
> 
> I agree that some administrators might not want Session-ID to be removed.
> 
> 
>> Are there any examples of other headers that
>> implementers of 3323 have not removed based on the
>> clause in section 5.3?
> 
> I assume that vendors have applied the concept in a variety of ways with
> various degrees of configurability.
> 
> 
>> Do you have a strong opinion either way?  I can see
>> arguments for and against removing it, so I don’t have
>> a strong opinion.
> 
> I also do not have a strong opinion.
> 
> 
>> Either way, does it bear mentioning in the Session-ID
>> specification?
> 
> Depending upon interpretation, draft-ietf-insipid-session-id and RFC 3323
> have conflicting mandates.
> 
> If the working group desires a specific behavior, it should likely be
> discussed within the draft if RFC 3323 causes an ambiguity or conflict with
> the desired behavior.
> 
> If the intermediary removes the Session-ID, I assume that a different (or
> maybe the same) intermediary might add a different Session-ID.
> 
> As usual, the topic of privacy related to lawful intercept doesn't need to
> be discussed.  I assume that some vendors will implement conferenced lawful
> intercept as not being a conference.

v2.23.0 | Report a Bug | By Email