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

Brian Sipos <BSipos@rkf-eng.com> Fri, 27 September 2019 18:23 UTC

Return-Path: <BSipos@rkf-eng.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 4595212090D; Fri, 27 Sep 2019 11:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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=rkfeng.onmicrosoft.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 UOxOyIFHjACm; Fri, 27 Sep 2019 11:23:55 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800085.outbound.protection.outlook.com [40.107.80.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62D012091D; Fri, 27 Sep 2019 11:23:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n3mj6knyYyEneVkXDXqvJ2H//pPCwknJVc1tzwFhjX0JKtL6zN1ggsSAdT7VDWZ1ia36s7Uqm4GGy9m3uKrh+1YlGZGKrhKY3m3PQficQQBUkdfLOU9jqTUyDF9Wn9F19SqVDe1L+hKUtpUP/kXxlDkWG3rySUo0CGTQHpAqam+abgD+TFM8vzBDKuwRy3tEc2eSHdaGaJBJcs0wg4v3naDwqiJIxw8NKe3y1rT4Umr81xAX8DEA0BuSXFd4RpBZHNv299R3qUjbJdKFYmsi20ydQn/q1Xf34Aa6uyQvQWeqL+WrOe/FWYko26Tm2HR31hm54HJesDvkbjOai2+VsA==
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=6+ZN4XVGx5QXv0ob6c/rZtjV5XI/KxdagWGRYkrYwaU=; b=TCgESXbViVOOsP8Bz2mAeiLo4WAJwWQGkIt4cgzd6DQ1T93fuyoo+W6BPPgE9tIPe11UEaJjZXfOBYkF2OUkt4+zEui87qCMqCNeYBq+UHqyaVd4VReUJYFRYauSmGtLZuadM4ZeMO+6S82h0RWiADWLaNyeoUvQTvZhNc1t7p92LfTFg2zpSzkWV2UmpVXEV3rBga2YE0diIs802yIi1iqLisxW41gpP/QUbirWyO16U2iPYmWAd9inlVWfMFgg8zZzF7aFcZ0QZPEjEWyylmkxL3kZvtr99u+R9tKCvI94HMuQltgkJaF3Y/4W1Rhzyemh5sOG/Ew4h6hxmWEkFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6+ZN4XVGx5QXv0ob6c/rZtjV5XI/KxdagWGRYkrYwaU=; b=nJJndzfVnWNo2Lq07sLuoPlc2JlQgSc48O5kw0xH8CSnWiBT1T4r52JQizeHrpyL6LqS20SAUVpKAzYuTeEzEYhCZvkgJv8l77aaV3CFuC28q3juBBKDOCUsYmmwT/apmLhsBbwNX83vvmom87daZJv3rR+8fBeiesw0v+xRFvo=
Received: from BN8PR13MB2611.namprd13.prod.outlook.com (20.178.218.81) by BN8PR13MB2754.namprd13.prod.outlook.com (20.178.222.10) 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 18:23:50 +0000
Received: from BN8PR13MB2611.namprd13.prod.outlook.com ([fe80::d1fb:dec5:245c:aef5]) by BN8PR13MB2611.namprd13.prod.outlook.com ([fe80::d1fb:dec5:245c:aef5%7]) with mapi id 15.20.2305.013; Fri, 27 Sep 2019 18:23:50 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: 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>
Thread-Topic: [dtn] AD review of draft-ietf-dtn-tcpclv4-12
Thread-Index: AQHVdTEl2KgTuarat0KdPeTeXQd+xQ==
Date: Fri, 27 Sep 2019 18:23:49 +0000
Message-ID: <BN8PR13MB2611999367F93B013AD15EE79F810@BN8PR13MB2611.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=BSipos@rkf-eng.com;
x-originating-ip: [66.195.166.226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 67c372b7-ba0d-4217-e216-08d74377d81e
x-ms-traffictypediagnostic: BN8PR13MB2754:
x-microsoft-antispam-prvs: <BN8PR13MB27547657286C7C1DECF7306E9F810@BN8PR13MB2754.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(376002)(39830400003)(346002)(189003)(199004)(486006)(33656002)(105004)(74316002)(66066001)(66946007)(8676002)(66556008)(66476007)(76116006)(81156014)(64756008)(2906002)(66446008)(25786009)(102836004)(7696005)(6246003)(99286004)(53546011)(7736002)(186003)(26005)(2501003)(6436002)(81166006)(52536014)(5660300002)(55016002)(8936002)(71190400001)(508600001)(316002)(476003)(6506007)(6116002)(14454004)(71200400001)(80792005)(14444005)(3846002)(256004)(86362001)(54896002)(19627405001)(229853002)(110136005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR13MB2754; H:BN8PR13MB2611.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: rkf-eng.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hhe77Z4prgdsidORcI+CL6AxglpLz2DFJBb9Ozs64gxB9NQL5+oHG0tzwOHBPo7C88LVQ3JtP0qrg7SgkMfpq5bcrYytQWatTy/5Z4kfI1AXm+s2i6yb68fj0oXKff4cdq/gSVfX+HUaYasCvMN0xteCLyCu6wIJ2YjfpxW4evA/mJ0I6G5eqaMHWuzfGjlhUMpBGZYIHyfBVVj6jXY4QiW7pX3ai58mSTSDtIMgVCZDOCqM7wfAV/7fCoqnak0Iv06PjPivWTLXUrLySDM43HLU2cD+1hnIeArN8yt8YsT7HuYxyigoqNkzCPt+ZZ8447WjMONgGvsWf6L4mijOXgA5iCIM8dwTslIwvvuPOjmN13/cnXfpRxAX9Hd5k8EV2WGn1vMhg37PGKQf71M04QxKZnXwkH1ZVyMlQMcwoKU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR13MB2611999367F93B013AD15EE79F810BN8PR13MB2611namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67c372b7-ba0d-4217-e216-08d74377d81e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 18:23:49.9847 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NCn3gl+wuL1DR2FtJ1nAF1XyFi5DXq8lH/bACqzl7fWEHw7oB2EvPNrI+kGLCARf7tazg6PBV3tn5tMTVVkaTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR13MB2754
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/ekBUjxyubgENVq7zNyXFU_vYiqs>
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, 27 Sep 2019 18:23:59 -0000

Magnus,
>From your earlier message regarding BCP 195, that is excellent news that no change is needed.

Regarding SNI, your expectation is correct and the current phrasing is not explicit enough. Where it says:

The SNI SHALL contain the same host name used to
establish the TCP connection.

it should more accurately say:

The SNI SHALL contain the host name of the passive node
which was used to establish the TCP connection.

There may be a yet nicer way to phrase this; any suggestions are welcome.

________________________________
From: Magnus Westerlund
Sent: Friday, September 27, 2019 04:30
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,

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 node4.foo.com which maps to an ip 100.10.10.50:5432. The fact that
when Charlie is establishing the TCP/TLS connection it will do a TCP connect to
100.10.10.50:5432 and then the TLS SNI Field says "Charlie". How will the server
entitiy at 100.10.10.50:5432 location know that Charlie is suppored to talk to
node4.foo.com rather than node9.delta.com if they actually are co-located? I
would have expected that SNI would indicate the host, in this case node4.foo.com
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.

Cheers

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
----------------------------------------------------------------------