[netconf] proposal for tcp-client-server draft

Kent Watsen <kent+ietf@watsen.net> Thu, 06 June 2019 00:58 UTC

Return-Path: <0100016b2a4ba167-46e45e4f-a2f3-4327-87d5-22da10aad5fe-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D2801200F7 for <netconf@ietfa.amsl.com>; Wed, 5 Jun 2019 17:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p4NCLSKXVxQB for <netconf@ietfa.amsl.com>; Wed, 5 Jun 2019 17:58:49 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D38120025 for <netconf@ietf.org>; Wed, 5 Jun 2019 17:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1559782728; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Anin7BQOkkiLNBhJVuQKmjnlGiXcyEUOVDHGbjEELEQ=; b=YVurTprFro1gaHb3Wln+vCJZqlZBBdWnn8Gf7ssc/oEuW8AN7OcIIYPfFDOkIYgN /SbBSsy6dvg4FMdCvihXmpfvWKeLZC/WWGTcpyUwXh/JG33kXFYYx3/FvcBz4UgFd0+ ttMVStUwcbk4aq9nvSkAFd/49moPK65M6AZ0BoRI=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE6096BA-0265-42E1-8F92-7BFDB15EDF1E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <0100016b2a4ba167-46e45e4f-a2f3-4327-87d5-22da10aad5fe-000000@email.amazonses.com>
Date: Thu, 06 Jun 2019 00:58:48 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.06-
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bZalr8hrqHYub8Xm_cdmZ_vkvGc>
Subject: [netconf] proposal for tcp-client-server draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 00:58:52 -0000


I'm working on a project for which the server is behind a NAT (e.g., a load balancer and/or TLS terminator), and the server needs to sometimes send out messages containing respond-back contact information (e.g., a URL to confirm the activation of a user account).  In these cases, the hostname/address it sends is not its native value, but rather the value used by the NAT fronting it.  Furthermore, the server may have multiple interfaces, each with different values (e.g., NBI, SBI, EBI, etc.), each potentially fronted by a NAT.  Using the client-server stacks, it makes sense to capture this information in the TCP-server model, the lowest common denominator.   While my application-level model could augment-in nodes to capture the NAT-ed values, the scenario seems common enough to warrant placement in the base model, albeit enabled by a feature-statement.  I'm thus planning to include some provision for this in the next TCP-server model update, so that it is captured and thoroughly discussed later.

FWIW, I'm tempted to make a symmetric update to the TCP-client model to support outbound proxies.  For instance, the ietf-http-client module already has a "proxy-server" node; however that node contains TLS/HTTP client/server authentication parameters, which would be inappropriate to capture in a TCP-level node.  For this reason, I'm not planning to make the symmetric TCP-client change, but rather leave it here as something for folks to ponder.

Kent  // contributor