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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 20 September 2019 10:12 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 3ECFD12001A; Fri, 20 Sep 2019 03:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 gIKxJRVjyZT1; Fri, 20 Sep 2019 03:12:36 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AFE12011D; Fri, 20 Sep 2019 03:12:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 593A1BE58; Fri, 20 Sep 2019 11:12:32 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqiTgWjKkNZu; Fri, 20 Sep 2019 11:12:32 +0100 (IST)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14656BE51; Fri, 20 Sep 2019 11:12:32 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1568974352; bh=0xWJUf4b5KrCBOgl1PICEydosbW1rf7o9gzNXi9i/IU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sQEmZ5BiRhY+AUFBNPZjBVB5D65pwwR9jxxK28rn8V1urbrUvds12gVhlh0Tl0/je H14NNp3i4Wl/xTE+vD9al/UbGoOW65MU4ERfqhGZPY2gilFgoxtKi2bUejUn6HVF0n H6E3CyWWAnUlRVEOPA4ePJ9CiqWpxh8RJ31+mw0Q=
To: "Taylor, Rick" <rick.taylor@airbus.com>, Brian Sipos <BSipos@rkf-eng.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "dtn@ietf.org" <dtn@ietf.org>, "magnus.westerlund=40ericsson.com@dmarc.ietf.org" <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>
References: <BN8PR13MB26118DD1DFB48E126B979D0A9F890@BN8PR13MB2611.namprd13.prod.outlook.com> <210a0ab6dbb9489fa4ac650d714d7649@CD1-4BDAG04-P04.cdmail.common.airbusds.corp>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <c510d1a2-f693-703b-8d77-21f40ed9047a@cs.tcd.ie>
Date: Fri, 20 Sep 2019 11:12:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <210a0ab6dbb9489fa4ac650d714d7649@CD1-4BDAG04-P04.cdmail.common.airbusds.corp>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vn9SX9xvvHdA6PMy1AY0UEHzdJzanOl3t"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/iU_bctjKJK_a54BoovFKry-nC0Y>
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
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: Fri, 20 Sep 2019 10:12:40 -0000


On 20/09/2019 10:21, Taylor, Rick wrote:
> Hi Brian,
> 
> I think you may have just clarified the issue for me, and I agree.

+1

> 
> Given this is a TCP convergence layer, the SNI should assert identity
> at the TCP/TLS/DNS layer, irrelevant of what the DTN layers above are
> doing.  As a sysadmin, I want to know that when my TCP-CL connects to
> 'dtn.airbus.com', it can validate a cert with an SNI of
> 'dtn.airbus.com', not some DTN EID.
> 
> Am I right in thinking that an SNI can also be a dotted IP address,
> or am I misremembering X509?

I'd say YMMV in terms of how well that'd be supported.
In theory yes an SNI value could be an IP address and
that IP address could be in an x.509 cert too, but I'm
not sure many libraries/applications will correctly do
the matching/checking on the server side. I'd have to
check, but would guess that most off-the-shelf libraries
or applications compare the SNI to the dnsName variant
of the cert subjectAltName and not an ipAddress.  The
upshot might be such a TLS session could fail or could
select the default TLS server cert, depending.

S.


> 
> Cheers,
> 
> Rick Taylor Product Design Authority, Mobile IP Node Principal
> Engineer (eXpert), Mobile Communications Airbus Defence and Space 
> Celtic Springs Coedkernew Newport NP10 8FZ
> 
> Phone: +44 (0) 1633 71 5637 
> rick.taylor@airbus.com<mailto:rick.taylor@airbus.com>
> 
> www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>
> 
> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Brian Sipos 
> Sent: 19 September 2019 16:29 To: Magnus Westerlund; dtn@ietf.org;
> magnus.westerlund=40ericsson.com@dmarc.ietf.org;
> draft-ietf-dtn-tcpclv4@ietf.org Subject: Re: [dtn] AD review of
> draft-ietf-dtn-tcpclv4-12
> 
> Magnus, Regarding the SNI, which I am in process of adding more
> specific text about:
> 
> Because a CLA necessarily deals with data in different layers (the
> transport and network layers below and the bundle layer above) there
> needs to be clarity about what is being identified in these sections
> and the SNI text is lacking. The purpose for adding the SNI  is to
> follow the same type of multiplexing that HTTP or similar services
> can provide. So the SNI would contain the host name used to establish
> the TCP connection and thus it would have exactly the same syntax and
> semantics as other protocols using the SNI. There would be no
> relation between SNI and any bundle-layer identifiers; only network
> layer identifiers.
> 
> ________________________________ From: Magnus Westerlund Sent:
> Thursday, September 19, 2019 07:14 To: dtn@ietf.org;
> magnus.westerlund=40ericsson.com@dmarc.ietf.org;
> draft-ietf-dtn-tcpclv4@ietf.org Subject: Re: [dtn] AD review of
> draft-ietf-dtn-tcpclv4-12
> 
> Hi,
> 
> Yesterday's interim meeting did discuss the EID and SNI relation and 
> our conclusion as I remember them was that the whole URI is put in
> the SNI field, and future scheme specific definition may define a
> sub-set of the URI is included.
> 
> Due to me reviewing another document that discussed TLS server name 
> indication (SNI) one thing did get flagged in my head:
> 
> So RFC 6066 defines SNI as a DNS Hostname, however the data type is 
> opaque bytes. However, an DTN or IPN URI is not a host name, so I
> think we may have a clash with what is written in RFC 6066:
> 
> Currently, the only server names supported are DNS hostnames; 
> however, this does not imply any dependency of TLS on DNS, and other 
> name types may be added in the future (by an RFC that updates this 
> document).  The data structure associated with the host_name 
> nameType is a variable-length vector that begins with a 16-bit
> length.  For backward compatibility, all future data structures
> associated with new NameTypes MUST begin with a 16-bit length field.
> TLS MAY treat provided server names as opaque data and pass the names
> and types to the application.
> 
> "HostName" contains the fully qualified DNS hostname of the server, 
> as understood by the client.  The hostname is represented as a byte 
> string using ASCII encoding without a trailing dot.  This allows the 
> support of internationalized domain names through the use of A- 
> labels defined in [RFC5890].  DNS hostnames are case-insensitive..
> The algorithm to compare hostnames is described in [RFC5890],
> Section 2.3.2.4.
> 
> Literal IPv4 and IPv6 addresses are not permitted in "HostName".
> 
> I think it is very worth asking someone with more insight into TLS
> what issues would arise if one attempt to put the general EID into
> the HotsName definition.
> 
> Cheers
> 
> Magnus
> 
> 
> On Tue, 2019-09-17 at 19:47 +0000, Magnus Westerlund wrote:
>> Hi,
>> 
>> Sorry about the delay in reviewing your update based on my AD
>> review comments. Below I have commented on my view how the issue
>> have been dealt with.
>> 
>> We appear to have a small number of things that are still not
>> fully resolved in my view so please chech these and comment.
>> 
>> I am also sorry that my mail client apparently eat the numbering.
>> 
>> 
>> On Thu, 2019-08-01 at 13:31 +0000, Magnus Westerlund wrote:
>>> Hi,
>>> 
>>> I have now performed my AD review of draft-ietf-dtn-tcpclv4-12.
>>> I think most are minor comments, however the TLS and security
>>> related ones may be more problematic to resolve. I will now be on
>>> vacation so you know you will not receive any quick replies from
>>> me before the end of the month.
>>> 
>>> Section 1: What are the applicability of TCPCLv4 to BPv6? I
>>> wonder as RFC5050 is referenced.
>> 
>> Thanks for the new scope section making things much clearer. My 
>> interpretation now is that this document only is for BPv7.
>> 
>> 
>> 
>>> 
>>> Section 1.1: Session State Changed. Some editorial issues.
>>> Missing ":" initially. Then double ".." on Terminated.
>> 
>> Fixed.
>> 
>>> 
>>> Section 1.1: Session Idle Changed  The TCPCL supports indication
>>> when the live/idle sub-state changes.  This occurs only when the
>>> top-level session state is Established.  Because TCPCL transmits
>>> serially over a TCP connection, it suffers from "head of queue
>>> blocking" this indication provides information about when a
>>> session is available for immediate transfer start.
>>> 
>>> So in which direction are this change indicated/reported, both
>>> or only in one of them, or any as implied by Section 2.1's
>>> definition of Live Session?
>> 
>> Fixed
>> 
>>> 
>>> Section 1.1: Transmission Intermediate Progress: Segment is not 
>>> defined prior to this. Maybe a forward pointe? Or should maybe
>>> the whole subsection (1.1) be moved to after definitions?
>> 
>> Fixed
>> 
>>> 
>>> Section 2: Is there a point to use the RFC 8174 language that
>>> makes only capital words have special meaning?
>> 
>> Addressed
>> 
>>> 
>>> Section 3.1: "One of these parameters is a singleton endpoint 
>>> identifier for each node (not the singleton Endpoint Identifier 
>>> (EID) of any application running on the node) to denote the
>>> bundle-layer identity of each DTN node."
>>> 
>>> The above quote does imply something that at least BPBis isn't 
>>> making clear that a particular application agent would have its
>>> own EID. It is not clear that there are a one-to-one relationship
>>> between bundle nodes and application agents. Can you please
>>> clarify what the relationship is and lets figure out if that
>>> needs to be clarified back to BPbis.
>> 
>> Ok, so the new text addresses this.
>> 
>>> 
>>> Section 3.1: "Bundle interleaving can be accomplished by 
>>> fragmentation at the BP layer or by establishing multiple TCPCL 
>>> sessions between the same peers."
>>> 
>>> Are there clear rules established for how many TCPCL sessions in 
>>> parallel that may be established? By the end of my reading this
>>> is unanswered.
>> 
>> Answered, no built in limiation. Resource limited.
>> 
>>> 
>>> Section 3.1: XFER_REFUSE does that indicate that the bundle has 
>>> already been received. How else does one separate other reasons
>>> for refusing a bundle versus that one have received it prior?
>> 
>> I don't think this needs more texf, section 5.2.4 is clear on that 
>> the reason code will make resolve the reason.
>> 
>>> 
>>> Section 3:1:    Once a session is established established, TCPCL
>>> is a symmetric protocol between the peers. Double established
>>> 
>> 
>> Fixed.
>> 
>>> Figure 4: "Close message" is this TCP level message, if that is
>>> the case can that be clarified by prefix with TCP?
>> 
>> Fixed.
>> 
>>> 
>>> Section 3.2: Notes on Established Session states: Session "Live"
>>> means transmitting or reeiving over a transfer stream.
>>> 
>>> Session "Idle" means no transmission/reception over a transfer 
>>> stream.
>>> 
>>> Session "Closing" means no new transfers will be allowed.
>>> 
>>> Note that "Closing" is not used in Figure 4, it is called
>>> ending. Note spelling error on "live" receving.
>> 
>> Fixed
>> 
>>> 
>>> Section 3.2: Figure 5 and 6 uses PCH without explanation. Figure
>>> 5 could probably also benefit by expanding CH as Contact Header.
>> 
>> Fixed.
>> 
>>> 
>>> 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.
>> 
>> 
>>> 
>>> Section 3.3: "   Many other policies can be established in a
>>> TCPCL network between these two extremes."
>>> 
>>> The list above includes three items, so the two extremes needs
>>> to be enumerated.
>> 
>> Addressed.
>> 
>>> 
>>> Section 4.1: Can TCPCLv3 and TCPCLv4 coexist on Port 4556? Based
>>> on 9.1 the answer is yes, please clarify here.
>> 
>> Fixed
>> 
>>> 
>>> Section 4.1: "Therefore, the entity MUST retry the connection
>>> setup no earlier than some delay time from the last attempt, and
>>> it SHOULD use a (binary) exponential backoff mechanism to
>>> increase this delay in case of repeated failures."
>>> 
>>> Any recommended upper limit for the backoff?
>> 
>> 
>> Addressed
>> 
>>> 
>>> Section 4.2:    Version:  A one-octet field value containing the 
>>> value 4 (current version of the protocol).
>>> 
>>> I think the use of "the protocol" is unclear, maybe call it "the 
>>> TCP convergence layer". This to avoid confusion with BPv7.
>> 
>> Fixed.
>> 
>>> 
>>> Section 4.2: Please define how to set and ignore reserved bits
>>> in the Flags field so that it may be extended in the future.
>> 
>> Okay, it is defined to not be set, which is likely to be interpret
>> to mean that they should be 0. However, a lazy implementor could
>> also interpret that they do not need to set their bit-values at all
>> and may have a system that have random values at initialization of
>> a memory buffer. I would recommend to use ".. SHALL be set to zero
>> by the sender."
>> 
>>> 
>>> Section 4.3 and 4.4: Due to how the Contact Header relate to TLS 
>>> there is clear risk for a TLS stripping attack where the CAN_TLS 
>>> flag is cleared. I think there need to be some thought about
>>> mitigation of this weakness. Depending on the expected mix of
>>> entities and their capabilities one can either have policy for a
>>> deployment where one mandates TLS being used, thus preventing the
>>> bid-down by not being according to policy. It is more difficult
>>> to mitigate in a deployment where one have some entities that
>>> doesn't support TLS, unless one can some way securely learn which
>>> entities support it or not and thus can detect the manipulation.
>>> One can potentially also first attempt to do a TLS handshake for
>>> the best version one supports. Then run the CH inside the TLS to
>>> prevent TCPCL version and other flags to be manipulated. But that
>>> doesn't solve the down-bid. I did note the negotiation in Section
>>> 4.7 and the relation to Security Policy. Maybe the solution is to
>>> write some text on the risk of TLS striping in Section 8 and add
>>> forward pointers in 4.7 to that risk.
>> 
>> Section 8 text makes the biddown clear and indicates the policy 
>> mitigation. I think this is sufficient.
>> 
>> 
>>> 
>>> Section 4.4: Dealing with new TLS versions. BCP 195 does not
>>> appear to me to define how to deal with newer versions. However,
>>> as TLS 1.3 already exist I think this is from the start a
>>> relevant question.
>> 
>> I am asking the security ADs if it is current and sufficient with
>> the BCP 195 reference.
>> 
>>> 
>>> 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.
>> 
>> 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?
>> 
>> 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.
>> 
>> Sorry about being very cautious here. But, I know how much trouble
>> I have had with URIs and their application in the protocol when I 
>> worked with RTSP 2.0.
>> 
>>> 
>>> Section 4.8: Please define how to set and ignore the reserved
>>> bits.
>> 
>> Same as above about zero.
>> 
>>> 
>>> Section 4.5: Based on that many later sections just refer to the 
>>> Message Header, shouldn't the section title for section 4.5 be 
>>> Message Header? Now the first mentioning of "Message Header" are
>>> in Figure 16's title.
>> 
>> Fixed.
>> 
>>> 
>>> Section 6.1: After sending a SESS_TERM message, an entity MAY
>>> continue a possible in-progress transfer in either direction.
>>> After sending a SESS_TERM message, an entity SHALL NOT begin any
>>> new outgoing transfer (i.e. send an XFER_SEGMENT message) for the
>>> remainder of the session. After receving a SESS_TERM message, an
>>> entity SHALL NOT accept any new incoming transfer for the
>>> remainder of the session.
>>> 
>>> To me it seems that the above paragraph contains one
>>> contradiction. The parenthesis in the second sentence (i.e. send
>>> an XFER_SEGMENT message) appears to be false. Because as the
>>> beginning of the sentence implies that it can't start a new
>>> transfer. However SESS_TERM is allowed to be inserted in between
>>> XFER_SEGEMENT messages for a transfer ID, i.e.
>>> XFER_SEGMENT(ID=7), SESS_TERM, XFER_SEGMENT(ID=7, end) is an
>>> allowed sequence. Can you please clarify.
>> 
>> Addressed.
>> 
>>> 
>>> Section 8. If this identifier is used outside of a TLS-secured
>>> session or without further verification as a means to determine
>>> which bundles are transmitted over the session, then the node
>>> that has falsified its identity would be able to obtain bundles
>>> that it otherwise would not have.
>>> 
>>> I don't see how a entity could trust the in SESS_INIT provided
>>> EID more just because it is in TLS unless there are some
>>> mechanism for binding the EID to the TLS session endpoint (client
>>> or server). Some type of authentication is needed to prove the
>>> identity.
>>> 
>> 
>> I think the new text in Section 8 and the clarified TLS procedures 
>> resolves this issue.
>> 
>> 
>>> Section 8. Therefore, an entity SHALL NOT use the EID value of
>>> an unsecured contact header to derive a peer node's identity
>>> unless it can corroborate it via other means.
>>> 
>>> The EID value is not part of the CH, only SESS_INIT. Is this a
>>> left over from TCPCLv3 or earlier versions?
>> 
>> Fixed.
>> 
>>> 
>>> Section 8. Needs text on  TLS stripping attack due to the
>>> optional TLS usage.
>> 
>> Fixed.
>> 
>>> 
>>> Section 9: "In this section, registration procedures are as
>>> defined in [RFC8126]." ... defined as in ...
>>> 
>> 
>> Fixed.
>> 
>>> Section 9: "Some of the registries below are created new for 
>>> TCPCLv4 but share code values with TCPCLv3."
>>> 
>>> I don't think "share" is the right word here. Maybe "Some of the 
>>> registries have been defined as version specific to TCPCLv4, and 
>>> imports some or all codepoints from TCPCLv3."
>> 
>> Fixed.
>> 
>>> 
>>> Section 9.3: Is RFC Required unnecessary strict? Considering the 
>>> quite large name space, I would think that specification
>>> required would be a suitable policy? Just trying to understand
>>> what you think is gained by having someone publish the extension
>>> as an RFC, in any stream including the independent.
>> 
>> So this was changed to Expert Review and that is fine. Any 
>> registration requirements or special considerations for the
>> Expert?
>> 
>>> 
>>> Section 9.4: Same question as for 30)
>> 
>> Addressed.
>> 
>>> 
>>> Section 9.5: Here RFC required may be suitable. However, does it 
>>> make sense to allocate 2 or 4 points also here for
>>> Private/Experiments?
>> 
>> Addressed.
>>> 
>>> Section 9.6: Here I would consider Expert Review with a 
>>> specification requirement. I also do not understand why so much
>>> is reserved, a reason for that?
>>> 
>>> I would expect that the policy for 9.6-9.8 to be aligned so may 
>>> require change if change is decided on 33.
>> 
>> Fixed.
>>> 
>>> A big question I have after having read this document is how one 
>>> discover / determine the IP+port(s) to connect to for a given
>>> EID. Is this currently completely deployment specific? And how
>>> bound is this to Bundle routing?
>>> 
>>> What may be missing is the section that tells the intended 
>>> implementor that in addition to follow this specification you do 
>>> need a solution to the following things, like for example
>>> authentication framework that allows one to verify the TLS
>>> connects to EID mappings. Or an address resolution protocol that
>>> maps EID to IP address and port pairs for cases when routing
>>> simply give you Forward this bundle to EID using TCPCLv4.
>> 
>> So the scope of the document clarifies things and points to some 
>> needs. So I will consider this one resolved.
>> 
>> Cheers
>> 
>> 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: magnus.westerlund@ericsson.com 
>> -------------------------------------------------------------------
>>
>> 
---
>> 
>> _______________________________________________ dtn mailing list 
>> dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn
> -- Cheers
> 
> 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: magnus.westerlund@ericsson.com 
> ----------------------------------------------------------------------
>
>  This email and its attachments may contain confidential and/or
> privileged information.  If you have received them in error you must
> not use, copy or disclose their content to any person.  Please notify
> the sender immediately and then delete this email from your system.
> This e-mail has been scanned for viruses, but it is the
> responsibility of the recipient to conduct their own security
> measures. Airbus Operations Limited is not liable for any loss or
> damage arising from the receipt or use of this e-mail.
> 
> Airbus Operations Limited, a company registered in England and Wales,
> registration number, 3468788.  Registered office:  Pegasus House,
> Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.
> 
> 
> _______________________________________________ dtn mailing list 
> dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn
>