Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Magnus Westerlund <> Fri, 27 September 2019 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0869D120899; Fri, 27 Sep 2019 01:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cx3aPUhOZvm5; Fri, 27 Sep 2019 01:30:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 415CD120829; Fri, 27 Sep 2019 01:30:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=kAyI4TIKn3wfbuwpiSLutejjqBEDtKNaghcjHWtMhBUYSSm8jLrOeYOcYjBhWVMPF2yvvIuEKSotArRJ7xVfFJ4KgPHE9OFcIG9BqDFgyVConjfyi1pJO2rJrqPiYLX7KmQTkdpOJBX6gkNE1es44d+CcNh6JkxkWmZK0d1vfIFes4qj28rbovAJKCDLfFEl7CCWoQf83zFt5vmhvRZFd6BOh2WQXq5vmU2KBLzDDmh3jtC9y5bVizNVtSdcDAE+uUVNLR7Pf6FylbJ9CPkTB9oL5stT5aI/KH0prw2ETFTisBQNW7bOQh510YMOeRTP3xeYqWEVrVg9D3CbPNX0ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V32oXHL+07oN0ndm8qXIEN69cg/VDCvAWXX9yZMDXdo=; b=MesqUzk/BgSgkJbEsPpB6B/GcUu3tECrpEFR8qT/rqKoFfh9R9LBLGUFQcXZGcbNSCYfiZ8LznkAQL6pjFHz+eHydaHfEFQwg40UDHAcOJQrrWYuye6MfrvHRiXI3uJNeEni2ea8dVB0QXh4yiTAdcz+av3ebKWRJoMc0xalDmhc5tjz12MkTLGN96HSlTVqny4CDMZN7LZJsraFHrG1neFWVEPE7/YSicjMW8KpQqG74oaONZ5oYlmItWGi7BVi3yE0P1ZxQwlEDlPPHvsn4kjbjozzpFcIBqNCOEQ5wrSdOZmMod8QD8TfU77Ln78R2d70Z+LPlpz2vQbj8S2f5Q==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V32oXHL+07oN0ndm8qXIEN69cg/VDCvAWXX9yZMDXdo=; b=Uyi2Bn7X/iXYhDzjfeO8RiClMXTCl0RNmvGtjYbYLgNZybq28zNzc6pErxXkqK5JmsXRXWWCKBosTIYmWH6/lqJ3pZu4sBSFnYbtPWnaiZ9kczt0GMqk20Xe7xkLrM4WhKDqjVfkMmt0KEqISypG3HbdtUWEK4lzjHxv0T8QOF0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Fri, 27 Sep 2019 08:30:39 +0000
Received: from ([fe80::e48c:a942:9682:2ce4]) by ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 08:30:39 +0000
From: Magnus Westerlund <>
To: "" <>, "" <>, "" <>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AdVG21EHJDIckyVtR8mDiK6Q+2uHtgmtVlwAAd9K/oA=
Date: Fri, 27 Sep 2019 08:30:39 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 65451a9f-8268-42b0-97ca-08d74324fa67
x-ms-traffictypediagnostic: DB7PR07MB3929:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(346002)(376002)(136003)(396003)(189003)(199004)(256004)(14444005)(71200400001)(26005)(71190400001)(186003)(76116006)(64756008)(86362001)(8676002)(66556008)(66446008)(66616009)(66476007)(91956017)(110136005)(316002)(14454004)(25786009)(81156014)(11346002)(8936002)(36756003)(446003)(81166006)(508600001)(2501003)(2616005)(66946007)(6246003)(305945005)(476003)(486006)(66066001)(6512007)(102836004)(2906002)(6486002)(229853002)(44832011)(5660300002)(99936001)(6436002)(6506007)(76176011)(6116002)(3846002)(7736002)(118296001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB3929;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UCL7xg1jIee6u2K2MVDB7Vbo3Oq8VTZX0iu4BNjrXQ5crJQkuqwyFEUdiz28IQZhCQQy39YRu3mPMi+DMESDOxP0368me5idGYBjWbYF4dhm00A2py6h/uucbmTMFhyftzISbMfy6i7/NHg48NSfeHI47AjLoOLXeBI4pqi2kCX6TCMaPcTwauYRt5O3ijQgrsjAj3Onxke+NV27mN7W6XDbCwe/hY+/ueG7jHHAUK2p+gi+KajI+R0lo/VzR1yNnjZtD13gCAP5frI2uVhCz80Z/3LVdXAdUL4Jp1EiP0z5Tz+pDqC6SAknt2ncLR6BWPSMqjzgCu1/OSXDI2K4srN/1RD3nWfMxfFW6pvc3FsyG6nirhREzBWgB7906gfvcsZaZm7mxP5CY0L7IkP4Qy/tHRdW9Ep3sF9dqqcCWH0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-P37driNt+8jHfMVOZJ03"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 65451a9f-8268-42b0-97ca-08d74324fa67
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 08:30:39.4111 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vHS72RirMaBxz8TavCbOh4F+QiN10kqDoKHoaHky/9UVZS0xtdT7lNaF8Q4xEpU5Dmj2i4Q2yWwrC14Qmvewcu4BQeHMylqbvxKqHjO1QNQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3929
Archived-At: <>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Sep 2019 08:30:55 -0000


So looking at -14 I think the remaining issue is only the question if the SNI
field is the right one. I think you may have to educate me here that this is the
right way. However, please my comment below. 

On Tue, 2019-09-17 at 19:47 +0000, Magnus Westerlund wrote:
> > Figure 8 and 10: Uses [SESSTERM] is this the same as using the
> > SESS_TERM message, or some other procedure. Please clarify. 
> Okay looking at this again it is clear that [SESSTERM] is used for any
> type of session termination. However, as SESSTERM appears to only be
> used in the figures in that meaning, and being defined in Figure 13,
> despite existing in 8, 9 and 10 also. Also considering that Figure 13
> and 14 are signalled termination and the other are failure cases I
> think a sentence or two should be spent to explain its meaning prior to
> its usage. 

The changes do make the process around SESS_TERM message clearer. I think this
is now resolved. 

> > 
> > Section 4.4: So what about entity authentication? Will the TCPCL
> > entity have a name / identity that can be authenticated so that one
> > know that one are talking to the right entity. And is the solution
> > for this a classical PKI, or something else? Also does the passive
> > entity expect the active (TLS client) to authenticate itself also? 
> Mostly good new text on the authentication. Here I am going beyond my
> expertise, but based on that RFC 5280 has been updated several times, I
> think you need to figure out if any of these updates should be
> indicated as necssary for TCPCLv4. The relevant updates are RFC 6818
> which makes clarifications on RFC 5280 and then the intenationalization
> in RFCs 8398, 8399. 

This part is resolved. 

> The other concern I have is the SNI sentence: "The TLS handshake SHOULD
> include a Server Name Indication from the active peer." First of all
> you need a reference for server name indication. It is an TLS extension
> and not included in the main TLS specification. For TLS 1.2 it is
> section 3 of RFC 6066. The second part is that I don't think it is
> clearly specified what should be in the SNI field in TLS. Looking at
> the DTN URI scheme definition I would guess that only the node-name
> part of the URI should be included, or? 

The new text is very clear on how the SNI field is to be used. However, now it
is Client Hostname Indication rather than the Server Name Indication field.
Without understanding the name and addressing schemes of DTN I have a hard time
to judge if this makes sense or not. I find it a bit backwards to say the least.
If a BP Agent (Charlie) has bundle that is to be delivered to dtn://foo/bar and
does a name resolution of "foo" to learn that foo supports TCPCLv4 and has a
host name of which maps to an ip The fact that
when Charlie is establishing the TCP/TLS connection it will do a TCP connect to and then the TLS SNI Field says "Charlie". How will the server
entitiy at location know that Charlie is suppored to talk to rather than if they actually are co-located? I
would have expected that SNI would indicate the host, in this case
rather than Charlie.

> This also relates to the section 4.4.2 TLS host name validation part.
> It says that certificates subjectAltName should be the Node ID. That
> raises question marks as no part the DTN URI format defines something
> as Node ID. The second is what happens if someone uses another URI
> scheme with BP? Or maybe this is simple to resolve if the whole URI
> should be used, but that looks less than obvious at least in the case
> of DTN. And I haven't looked at the IPN scheme. 

To me this part now looks clear. 


Magnus Westerlund 

Network Architecture & Protocols, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: