Re: [Netconf] [netmod] draft-ietf-netconf-netconf-client-server – TCP keepalives

Kent Watsen <kwatsen@juniper.net> Tue, 12 June 2018 01:22 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B293B130EAC for <netconf@ietfa.amsl.com>; Mon, 11 Jun 2018 18:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 OtzXFN2AjQPN for <netconf@ietfa.amsl.com>; Mon, 11 Jun 2018 18:22:47 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 65897130DCF for <netconf@ietf.org>; Mon, 11 Jun 2018 18:22:47 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5C19WFV010120; Mon, 11 Jun 2018 18:22:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=V0ZL1rxuQaUTPL/5bpf8qjfNwv2cLuofVIyX8y4Tapk=; b=Vn7C06KYQjBvY4SJLZsTObMPXjAKxF8Mo6eXVOCTFvvwYF4XQoEdTGRUjBS5GfPbPO4q W7rYWrlL/KC3B+lL8NWk1oJmM/PPGqwamNV6bBbXOTJ3FHBt+ODEtfucKuTsOx3EfSyO Xqp52KThiCJwzOO/AzpBEo4t/N39/RO4/G+p4ZMim7NAt2+lLaHv994DMHFSWakh1GeT ZgCkgShdg9kpVynoKjWrCP4qVVK07aGGKYYZ84KLKmNeOf0R24ZP0dzm9/rjCSI2GIW6 HLPB+clsOis2l7chnzkQN/HNC70JVjnKmD3n+qfCFyh6Em/jzr4YciUppPIUeIOqMLp+ rg==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0b-00273201.pphosted.com with ESMTP id 2jj07r0dgn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 18:22:43 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4550.namprd05.prod.outlook.com (52.135.203.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Tue, 12 Jun 2018 01:22:41 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%3]) with mapi id 15.20.0863.010; Tue, 12 Jun 2018 01:22:41 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: NICK HANCOCK <nick.hancock@adtran.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: =?utf-8?B?W05ldGNvbmZdICBbbmV0bW9kXSBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29u?= =?utf-8?B?Zi1jbGllbnQtc2VydmVyIOKAkyBUQ1Aga2VlcGFsaXZlcw==?=
Thread-Index: AQHUAevaufYdiXPed0mTXCyVjCGOOg==
Date: Tue, 12 Jun 2018 01:22:40 +0000
Message-ID: <51912D52-547F-475F-B71C-A87361DB5690@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4550; 7:TR3Dgkanop0fA/7jtdBOz3F6KXI00Nkc4Uefo248P+HC3W9PNRhx6P7biROSbCee/7uZZMyzr5B3OQANvOMlB4kJx+HmlZXFfEHdHtzqnhrl8B8JgURyAmORVbn7Y22ggCJ1nn87H2ooAcy5/ucg0lb05iAdJJdkGaoxOIopoZG+1F0V+0a9FnHgP5d+Zg7JBcHCX+j4JftXYPk7ooqJp0TScGLgscE083XfAMI84FNxRG4DVS2wBWkSWRKFKm04
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4550;
x-ms-traffictypediagnostic: BYAPR05MB4550:
x-microsoft-antispam-prvs: <BYAPR05MB45503E323EED522738569A43A57F0@BYAPR05MB4550.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4550; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4550;
x-forefront-prvs: 07013D7479
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(39380400002)(346002)(366004)(53754006)(199004)(189003)(106356001)(186003)(26005)(966005)(5250100002)(575784001)(2900100001)(102836004)(476003)(6306002)(105586002)(97736004)(6246003)(478600001)(316002)(99286004)(58126008)(83716003)(86362001)(6506007)(2616005)(53546011)(8936002)(305945005)(486006)(59450400001)(6512007)(229853002)(7736002)(82746002)(33656002)(25786009)(4326008)(5660300001)(6916009)(3660700001)(53936002)(2906002)(6436002)(6486002)(36756003)(14454004)(81166006)(81156014)(68736007)(66066001)(3280700002)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4550; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 65Jp+JeZwSjtokf2OKEFRiIRfevSAIYeOYTBHqyoBxSsxvG6DqfEbsNKdoggn8+7Va7ATtnYzew0bPpyLSFMIgrZpdJnoDAmmRmGQvXjbq7V1c21TPhXBKYtyurdjFblR1MDNMmxv9jdtWCy9WSA0mJiR9ot5CLQUmsZePgZShSKNvBP4jUq2fwBgFDO2Lg6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <25D76EF38277EE47A915641EF938A1BA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 817f13f1-89dc-48f0-1bba-08d5d002fde7
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 817f13f1-89dc-48f0-1bba-08d5d002fde7
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 01:22:41.0461 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4550
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120011
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/LpBC6qtPudCXmM6UbqnxiF_bfTM>
Subject: Re: [Netconf] =?utf-8?q?=5Bnetmod=5D_draft-ietf-netconf-netconf-clie?= =?utf-8?q?nt-server_=E2=80=93_TCP_keepalives?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing 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: Tue, 12 Jun 2018 01:22:52 -0000

Looking into this just a little more, I know that Heartbeat was supported by OpenSSL before (recall Heartbleed bug?), so I grepped the 1.1.0g source code (which has the Heartbleed fix) and found evidence that the support might still be in the code.  That said, I can't tell if the code is specific to DTLS or works on TLS as well…

/kw


===== original message =====

[+netconf, -netmod]

The issue appears to be with current TLS libraries not implementing TLS keepalives, the HeartbeatRequest messages defined by [RFC6520].   I have not myself validated this yet, does anyone have any experience?

If it is true that HeartbeatRequest messages is not supported today, do we:
  a) encourage the TLS library maintainers to implement it
  b) or introduce an ability to configure TCP-level keepalives
  c) or both?

Any other ideas?

Thanks,
Kent



On 6/11/18, 12:32 PM, "netmod on behalf of NICK HANCOCK" <netmod-bounces@ietf.org on behalf of nick.hancock@adtran.com>; wrote:

Hi All, 
 
A couple of companies are working on a solutions to implement devices, such as DPUs, based on the requirements of the Broadband Forum Technical Report TR-301 issue 2 “Architecture and Requirements for Fiber to the Distribution Point”, which requires TLS for the persistent NETCONF connection, for which the configuration of call home is to be by means of the ‘ietf-netconf-server’ module. 
 
TLS heartbeat cannot be supported to keep the call home connection alive, because TLS heartbeat is not or no longer supported by many TLS libraries, such as OpenSSL in the wake of the Heartbleed security bug. Although TCP keep-alives are not secure, we will nevertheless be required to support TCP keepalives to ensure that the connection remains persistent and these keepalives would also need to be configurable. Unfortunately, the keepalive configuration implemented in ‘ietf-netconf-server’, although not bound to the ‘transport’ choice, is bound to the secure layer textually in the description of the data nodes (references to “SSH/TLS client” and “SSH/TLS-level message”), which makes its use for configuring TCP keepalives for specific implementations possible, but obviously problematic. RFC 8071, Section 4.1, S7, also heavily implies that it is intended to be used for the designated transport layer (e.g., SSH, TLS).
 
Since this issue affects the industry as a whole, we believe it would be better to provide support for the configuration of TCP keepalives within the ‘ietf-netconf-server’ module from the beginning, rather than wait for other SDOs or vendors to augment the module after publication as an RFC, which they will be practicably forced to do.
 
Would supporting TCP keepalives in the IETF-defined module be something the WG would agree to discuss? A possible solution, shown below, could be to add a new container parallel to the existing ‘keep-alives’ container to explicitly support the configuration for TCP keepalives. In addition, a feature statement (e.g. "keep-alives") could be added to the existing ‘keep-alives’ container, as RFC 8071 S7 says SHOULD (not MUST). 
                   container tcp-keep-alives {
                     if-feature tcp-keep-alives;
                     description
                       "Configures the keep-alive policy, to
                        proactively test the aliveness of the TCP
                        peer.  An unresponsive TCP peer will
                        be dropped after approximately max-attempts *
                        max-wait seconds.";
                     reference
                       "RFC 1122: Requirements for Internet Hosts -- 
                        Communication Layers, section 4.2.3.6.";
                     leaf max-wait {
                       type uint16 {
                         range "1..32767";
                       }
                       units seconds;
                       default 30;
                       description
                        "Sets the amount of time in seconds after
                         which if no data has been received from
                         the TCP peer, a TCP-level message
                         will be sent to test the aliveness of the
                         TCP peer.";
                     }
                     leaf max-attempts {
                       type uint8 {
                         range "1..127";
                       }
                       default 3;
                       description
                        "Sets the maximum number of sequential keep-
                        alive messages that can fail to obtain a
                        response from the TCP peer before
                        assuming the TCP peer is no longer
                        alive.";
                     }
                     leaf interval-between-attempts {
                       type uint16  {
                         range "1..32767";
                       }
                       units seconds;
                       default 30;
                       description
                        "Sets the amount of time in seconds after
                         which, if no reply to a keep-alive message
                         has been received from the TCP peer, the
                         next keep-alive message will be sent.";
                     }
                   }
                 }
 
 
What is the opinion of the list? Would this solution work?
 
Best regards
Nick & Yves
 
 
 
 


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=n1Ew69P_92NcpKfb6HiepQwhe21v4fTuNEa-YZ_vs6s&s=CVqduXP2RuuZY7nPF0drm5h9oFCMIMGg0ux6shk88OI&e=