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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 24 September 2019 09:17 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 85148120803; Tue, 24 Sep 2019 02:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 syQOjqhqh8td; Tue, 24 Sep 2019 02:17:56 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00050.outbound.protection.outlook.com [40.107.0.50]) (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 850A312082D; Tue, 24 Sep 2019 02:17:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aER93OeekwhVPIOtpyHTmqCzi8C4grRelU72YFHyFPRhzQKGPPWzdJLM5gu+z9pyfYho/z5QsqmX4TBy22a5NtEGi8T6BJge7DOPfV8+b9GwXhv99IoPGlRgxxqV2L9XetIkiVthT9E+A+xkm0IyM1IKRR/MMTrJjdjRT3Tqyd5Wpo3vhrr7cdM7Y7H9xnZ7W5o3r40ChOP3Aoj1oz0VsGwkDY90KDhXAyxVBMCpTq7JSqwpvWPV2wxWfSEQJn846T2g9z2lN2kZ5hpofmDHwSBavVPVki1P9GZpQEIY7+yzv7674JSA4nR3lAeiEA6ZSORiHHqEZDHCC6+efx1wrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4T4wUWrG27bD+GtefYnur4SDKnP1fwiVuhG/TrEWfg=; b=UDrrWCoaaVlFJJs7MFYzkdSUHKLP12Ux5s+AUZdJC5mBIdXqfkgbjp/zJrZsT/j/krDecUuubH+zNdjTZM0dOrZCS2axsVEe22/7+E9Ba9p2AmTcFEoCj0WH0zEf4BBIcOnF+Cd19sm0P/nHKJzZt0StQEctZWHzzlYLGKYELgbj7ARu5C7QhG2sd1XZ9EHShszzpv5isDrwT9amoGsseU6EKaly7G3IjNQ69+Uf8tdVW16Ly6D7jamXpK60UgQFSfvv6vGaY4FvHzjBUd1GJwievMhV3e8v+FZ8c8OdTpAwr0w3/sV97/PyhvJKRNwNepBfjs6zP8euLETr/EgwcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4T4wUWrG27bD+GtefYnur4SDKnP1fwiVuhG/TrEWfg=; b=oAteA+Sd2WBJ3dMGdtbMtIw8ZQ8jyaB+0QPDwklYh1FQVzwUAO9W43xHj7D1xhDcL4itMk9CenpyMhBit+UzlnrYOOPSemnQdx7VSx6RfJBWGbKD2pl7VtoLHCeuhtjtjL/i9nJWN5t7WxCnL9VDU05uE33wmWtlrMi0zmRe8zQ=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5547.eurprd07.prod.outlook.com (20.178.45.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Tue, 24 Sep 2019 09:17:52 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2305.013; Tue, 24 Sep 2019 09:17:52 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "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>, "BSipos@rkf-eng.com" <BSipos@rkf-eng.com>, "rick.taylor@airbus.com" <rick.taylor@airbus.com>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVbvaTSw8eyJG5jUu1jaxcAQC2wKc0S4YAgACvc7qABZj6gA==
Date: Tue, 24 Sep 2019 09:17:52 +0000
Message-ID: <88819c562ea0fe2f8554742b2f3f3275967794d5.camel@ericsson.com>
References: <BN8PR13MB26118DD1DFB48E126B979D0A9F890@BN8PR13MB2611.namprd13.prod.outlook.com> , <210a0ab6dbb9489fa4ac650d714d7649@CD1-4BDAG04-P04.cdmail.common.airbusds.corp> <BN8PR13MB26114D3846AF641C59AFE93F9F880@BN8PR13MB2611.namprd13.prod.outlook.com>
In-Reply-To: <BN8PR13MB26114D3846AF641C59AFE93F9F880@BN8PR13MB2611.namprd13.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 11edad5e-8b2d-4dc9-04cd-08d740d0139a
x-ms-traffictypediagnostic: DB7PR07MB5547:
x-microsoft-antispam-prvs: <DB7PR07MB5547396A99792D73746A83AC95840@DB7PR07MB5547.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0170DAF08C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(189003)(199004)(51444003)(15404003)(51914003)(66446008)(11346002)(256004)(30864003)(14454004)(6436002)(6486002)(478600001)(5660300002)(66066001)(66556008)(66476007)(118296001)(229853002)(66616009)(2616005)(66946007)(44832011)(86362001)(446003)(64756008)(110136005)(305945005)(14444005)(8936002)(76116006)(91956017)(476003)(6506007)(36756003)(486006)(53546011)(102836004)(2501003)(7736002)(81166006)(316002)(76176011)(6512007)(8676002)(99936001)(15974865002)(71200400001)(26005)(186003)(966005)(25786009)(81156014)(3846002)(6116002)(2906002)(2201001)(99286004)(6246003)(6306002)(71190400001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5547; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rlz9m4ZIepzjEalQ04Obg4niQHw/ZZ1fqvDGvfnMWy+kduX8iQc7zh94ejDgg9YbsrumTXQW/MYVVn5213HUL2u2Y1A5+zrHJRkL4SeqRRShe8jGwKvXF8FNgHICYj8YX1B3orHgndOtzMrNhtqySs6kC4xFqNHQe2jY/3izlwu7bmCU4RUwMK486NPLYBTnJA2aN9OprH/7HA4cm7D34EGz/6pzsnQ1M10mSt+i4Rgde3xZaMA+oO7RPvxCFW9jzG89mZSucANz+I9BjOwjw5m+PiepM5FxlyNx8YZdk0I7rcXJrn9MfAAzdVnTl7PwVgmgRLGFbiHXhy71W9A+k1r4i2bez19qyoYFX5+UIaL9dIF/zK6ton4T8fvM0PrU69KE033Jqfsx06eEE1vPAu64Ip6QsQjDwc/dRK6/zLY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-oLGKHq3ewEVrNpiQRAQ2"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11edad5e-8b2d-4dc9-04cd-08d740d0139a
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 09:17:52.0791 (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: rLn07PRhZL2Vv/yz+kJLqfPKdf9rpE/3HOIze06CLii0ubXo0RPRkpKkP8G/Dx5GrKZqn7Hc0DuDNHFwrFhKQtJdrkI/RmGou3fXxhceMW4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5547
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/4v3hGnim_G7cy_kM93_YsJ_dL9A>
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: Tue, 24 Sep 2019 09:18:00 -0000

On Mon, 2019-09-23 at 13:12 +0000, Brian Sipos wrote:
> Rick,
> According to RFC 6066:
> > Literal IPv4 and IPv6 addresses are not permitted in "HostName".
> 
> so no raw addresses allowed.
> 
> If this seems like a niche enough use case then I'm fine with dropping these
> explicit requirements. Not having them in still allows the use of SNI (or any
> other TLS extension) it just makes it farther away from a standard practice.
> SNI enables "virtual host" type configurations where a single TCPCL passive
> node can function as CL for multiple BP nodes depending on the host name used
> to connect to it.

When it comes to literal IP addresses their being forbidden is likely due to
that they represent a massive risk in any co-location of hosts on a single IP
address. I think that risk do exists also for the DTN use case as multiple EID
and thus associated nodes can be co-located, even ones that are independent from
each other. 

Cheers

Magnus


> 
> From: Taylor, Rick <rick.taylor@airbus.com>
> Sent: Friday, September 20, 2019 05:21
> To: Brian Sipos <BSipos@rkf-eng.com>om>; Magnus Westerlund <
> magnus.westerlund@ericsson.com>gt;; dtn@ietf.org <dtn@ietf.org>rg>; 
> magnus.westerlund=40ericsson.com@dmarc.ietf.org <
> magnus.westerlund=40ericsson.com@dmarc.ietf.org>gt;; 
> draft-ietf-dtn-tcpclv4@ietf.org <draft-ietf-dtn-tcpclv4@ietf.org>
> Subject: RE: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
>  
> Hi Brian,
>  
> I think you may have just clarified the issue for me, and I agree.
>  
> 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?
>  
> 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
>  
> 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
----------------------------------------------------------------------