IETF Logo Mail Archive

Re: [dtn] BPbis and CL session identity

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Tue, 28 July 2020 12:54 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62F3A0C7A for <dtn@ietfa.amsl.com>; Tue, 28 Jul 2020 05:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 8EqEMBXhhKdZ for <dtn@ietfa.amsl.com>; Tue, 28 Jul 2020 05:54:18 -0700 (PDT)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83AE3A0BE6 for <dtn@ietf.org>; Tue, 28 Jul 2020 05:54:15 -0700 (PDT)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 06SCircV143495; Tue, 28 Jul 2020 05:54:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=0Onkc/P/SlYlKGEkQ6WGYcnysb1Y2hkNoOxls1AOff8=; b=mbgD9bLk3vEBqvqwqf2Mhg1d6jUpDVfU04rd515i1r7pJ82hPqelq71i0roE7/so45Ix goA2I2GtSfuq9Pb27/vZmDhsJr1oHD2uODU1grrfGJ84/S82BAXhF0Xm4Bxj7pIZhTC0 JRUVx3U4N+YswU4i0P+sk65BVncq5GnzA8W1vDKGyevS27JmTUU6VaxX0vBBCiJh9VO2 US+q2jMnuXhZPWfJDfcrwihOfsBSKMYjrcGaTWOtVE6hfl0SLctHQAdxRrJl0ZWwUY6T 9urKwoABH7veWchPyhQz/wNuVTtCQ9pUb2s2K/yfGRQ4CZ/EVfvvyf9RSjCs9MSsnAnG eg==
Received: from mail.jpl.nasa.gov (altphysenclup02.jpl.nasa.gov [128.149.137.53]) by ppa02.jpl.nasa.gov with ESMTP id 32gkwthv3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 05:54:14 -0700
Received: from ap-embx16-sp20.RES.AD.JPL (ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 06SCsDrR029943 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Tue, 28 Jul 2020 05:54:14 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp20.RES.AD.JPL (2002:8095:8954::8095:8954) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 28 Jul 2020 05:54:13 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1979.003; Tue, 28 Jul 2020 05:54:13 -0700
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Brian Sipos <BSipos@rkf-eng.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: BPbis and CL session identity
Thread-Index: AQHWZNWo88L9huko0UK09i3z+/kXZ6kc8gsw
Date: Tue, 28 Jul 2020 12:54:13 +0000
Message-ID: <90b802db712a49e484aaa74189dbf99e@jpl.nasa.gov>
References: <DM6PR13MB35624C8C57CB664E50902AF39F730@DM6PR13MB3562.namprd13.prod.outlook.com>
In-Reply-To: <DM6PR13MB35624C8C57CB664E50902AF39F730@DM6PR13MB3562.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_90b802db712a49e484aaa74189dbf99ejplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_07:2020-07-28, 2020-07-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2007280097
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/eDrzYKWi7OWT1e7rzNHAer31jGs>
Subject: Re: [dtn] BPbis and CL session identity
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 12:54:29 -0000

Brian, I agree.  ION implements option #1 but prints informational messages noting that the node ID asserted by the remote node is different from what was expected.

Scott

From: dtn <dtn-bounces@ietf.org> On Behalf Of Brian Sipos
Sent: Tuesday, July 28, 2020 5:11 AM
To: dtn@ietf.org
Subject: [EXTERNAL] [dtn] BPbis and CL session identity

All,
One point which was brought up at the last IETF, based on IESG review comments, is:
How should a BP Agent handle a situation where an attempt is made to establish a CL session with one Node ID and the actual session ends up being with a different Node ID?

This situation only apples to CLs which are session-based (or at least allow bidirectional data flow) and which present a BPA's Node ID to the peer. But this is applicable to the TCPCL (both v3 and v4) so should be worked out with some recommendation at least.

  1.  One option is to continue the session and any transfers which would have occurred to the peer BPA. Maybe assuming that the peer is multi-named and presented the "wrong" name for the network being used. Once a transfer begins, the peer BPA still has the opportunity to refuse a bundle because it doesn't like the EIDs in the primary block, etc.
  2.  The other option is for the BPA to terminate the session (with reason Contact Failure) right away. But then what? If there is no change in name-binding or routing information then the next attempt to transmit the bundle is likely to end up in the same situation.
I lean towards #1 just because it allows the BPA to do transfers and work out acceptance/refusal on a per-bundle basis. That behavior is also no different than a UDP CL or similar "fire and forget" CL.

What do current implementations of TCPCLv3 do in this situation?

v2.23.0 | Report a Bug | By Email