[DNSOP] WGLC draft-ietf-dnsop-session-signal

"Bernie Volz (volz)" <volz@cisco.com> Wed, 14 February 2018 02:18 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1512D7E3; Tue, 13 Feb 2018 18:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 n6xp14u8zZSz; Tue, 13 Feb 2018 18:18:47 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC2712708C; Tue, 13 Feb 2018 18:18:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17984; q=dns/txt; s=iport; t=1518574727; x=1519784327; h=from:to:subject:date:message-id:mime-version; bh=epjbreO49K4rIEY3AeGveM0q5A1iqPZrVUsVKs4IOYg=; b=RI9AibG0/X8wGOA57JJoGqc4+iyWZJS8DxJtAa64Zw97mCX5Oesc6hlx h6XsmkP2nlWyecfFX/HyYrmUr9/Z707II3UXvNCPFdWiOdTlkDVJ2BUkU v0+Q+WJ/TTGOhI2SNWsxjwvTtOWJkEob0TtQRkA/YMYdPNfq3vH/VByXr A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAAB7m4Na/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaSy1mcDKDW4okjiaDGZBmhVsVggMKH4U4gk5UGAECAQEBAQE?= =?us-ascii?q?BAmsohU1oAUoCBDAnBAGJY2QQsAWCJyaIWYITAQEBAQEBAQEBAQEBAQEBAQEcB?= =?us-ascii?q?YUBghWDPymGNAEBA4FFEQKDLTGCNAWKU4lwj2sJAogejWQOghGSJYsUgm6JaQI?= =?us-ascii?q?RGQGBOwEfOYFQcBVnAYIcg3oBAnmNZYEZAQEB?=
X-IronPort-AV: E=Sophos; i="5.46,510,1511827200"; d="scan'208,217"; a="69928512"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 02:18:46 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1E2IkYE025333 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 02:18:46 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 20:18:45 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Tue, 13 Feb 2018 20:18:45 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "draft-ietf-dnsop-session-signal@ietf.org" <draft-ietf-dnsop-session-signal@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: WGLC draft-ietf-dnsop-session-signal
Thread-Index: AQHTpToky7RwTvwCQEa3THbh85MkpA==
Date: Wed, 14 Feb 2018 02:18:45 +0000
Message-ID: <EBF6CCFB-C815-4D59-AEB6-29CA13F9DEFE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.253.42]
Content-Type: multipart/alternative; boundary="_000_EBF6CCFBC8154D59AEB629CA13F9DEFEciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/56NcwNBSY1K26tD424Z1sJtQqWU>
Subject: [DNSOP] WGLC draft-ietf-dnsop-session-signal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2018 02:18:50 -0000

Hi:

I have reviewed the document. In general, it is well written and ready to be advanced, though there are some nits that the authors should review and consider:

Section 1: Not sure why Stateful is capitalized in the following line:
transport protocol.  Each Stateful operation is communicated in its

Section 2: You probably should update this to the text in https://tools.ietf.org/html/rfc8174 and update the references accordingly.

Section 3: Do you want to add anything about Section 6 (and perhaps later sections)?

Section 4.2.2.3 (and perhaps other places similar text exists): When a connection is aborted because of an invalid message, is there any recommendation to be added about retrying? If the client terminates the connection, it would likely not be wise for it to immediately retry and repeat the operation as that can lead to an endless loop? Should some recommended backoff technique be provided? Or some other connection rate limiting warning?

Section 4.2.3, last paragraph: What should happen if a EDNS(0) TCP Keepalive option does appear? Should the connection be terminated? The message ignored?

Section 4.3: first paragraph: This text kind of conflicts with the text in 4.2.1 which says that whether a message is acknowledge or unacknowledged is determined only by the specification for the Primary TLV. I understand this may not be worth addressing, but perhaps a reference to 4.2.1 is worth considering?

Section 6.1: INACTIVITY TIMEOUT and KEEPALIVE INTERVAL. Is mention 0xffffffff (infinite) worth adding to this text?

For:

The Keepalive TLV is not used as a request message Additional TLV.
Would “MUST NOT be used” be better?

For:

A Keepalive TLV MUST NOT be added as to other responses a Response
I think “as” should be removed.

Section 6.2: I would assume 0xfffffff would not mean infinite.

Section 6.2.1: If a client were to receive a new RCODE but does not understand it (older version), should there be a statement as to how the client should react? Should it treat the unknown error code as if NOERROR were sent?

Section 9: Seems a bit light, but OK if it ends up being acceptable. For example, while it probably means you have bigger problems, but large timer values (such as in the Retry Delay TLV) could be a denial of service vector. Though if the server does that, it probably isn’t who you wanted to be talking to anyway and you should have used TLS.

Perhaps also saying that if DNS over TLS isn’t used (just plan TCP), then it may be possible for a man-in-the-middle to inject messages (such as with a large Retry Delay TLV)?


Again, nothing that likely MUST be fixed.


  *   Bernie