Re: [netconf] Question about RFC 6242 : netconf over ssh

"Jeffrey Ladouceur (jladouce)" <jladouce@cisco.com> Mon, 08 June 2020 15:39 UTC

Return-Path: <jladouce@cisco.com>
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 19A973A0909 for <netconf@ietfa.amsl.com>; Mon, 8 Jun 2020 08:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JvtogEyX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Iz0Wx+wR
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 i1BHg9ZfISfA for <netconf@ietfa.amsl.com>; Mon, 8 Jun 2020 08:39:08 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7BC3A07B0 for <netconf@ietf.org>; Mon, 8 Jun 2020 08:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4258; q=dns/txt; s=iport; t=1591630748; x=1592840348; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=JvtogEyXciK1XeFfWnfR17XZjfTvUjuYSj1XDMuzoLtsSZp8z8ujNjtO WD4gVIJbrCALlnfsZzpPcjeGFjPLj6WsXYzMxBjlqJADPcE17k/dMU+2u AHDog9fNQZOskqTlIn/Zo+NxaBAKUfC2OQ5StiDUXKt0Wkfti51c9Ow8A g=;
IronPort-PHdr: 9a23:XwAeExRL2+MB/SducWptmHYyodpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZURgDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR6cqXpTcOMQzmRtdl8=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CWCQA1Wt5e/4QNJK1mHgEBCxIMQIMcUgdvWC8sCoQag0YDphGCUgNVCwEBAQwBARgLCgIEAQGDf0UZgh0CJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVzAgEDAQEQEREMAQEsDBEBCBoCJgIEJQsVEgQBEiKDBAGCSwMuAQMLpSQCgTmIYXaBMoMBAQEFhVUYgg4DBoEOKoJkglEPhw0agUE/gTgcgk0+gQSBYwEBAgGBSi+CfTOCLY8GBIMDhlSKcZA4CoJZh0B3kE8DHZ5Ki3KFEYoAj3eEGQIEAgQFAg4BAQWBaiKBVnAVOyoBgj5QFwINkEAYg1qFFIVCdAI1AgYBBwEBAwl8jgUBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208";a="689767072"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2020 15:39:06 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 058Fd489004313 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2020 15:39:04 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 10:39:04 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 11:39:02 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 10:39:02 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGUQqGz8kxlU+bGpuld+ik9eMe9wBcMYt4H0OmVLbxAu+KMJ/pqnJxl2ec4s8Ow4LUBw4Z7SODv21I3sFyJQk4vwAAF8TkMO6nsFcbmry08tEsaxddOm/ZWJipEObyc2IpgjVRxPpXHSTV4r8RdtsUyRnbR2+OI6gyNXVBIJoK1NThnKwjfQIclax8Q87+lqTVCj7FyfXO+2uO4K+vSeBcTCmB8gze4F42Fx/f9/NmPpRTdNnVkhv9Sgp4hB4YaXm1+1p1egN3bc76y4RmuVawJCCQyyGq3nPKxChCsn33IpxrLklSTrRfJYBhw2f1XRhe1an8Z1jwQHr1oPE/IyUA==
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=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=EPPHfO1g931iZ1/WA6KwHCwD0/zk7WkImNusM3SyVPT4OhIrj5gc65u8xKlIIpLmdDgiUHY48JiSyaLFIiTUgPFHrV1aa0t5ylzeoaRmzU+KkhEBG7+h9/aepv8fa29W7Ub1KX/50bnXw92AoJASmSeKoKxIgWtao3nNsaPVcEtzcy+iYgAeRC49xOAnR4okNRd5QYIAZ0XwV1VlYWLbOdfmuO7cvtwP/2o8hON5iSKZS+rMis8XYlcAqPjW9IouvpEKLfFkqNqZHyF1coXPo4B5V519QAaPZXJZynTnTJSok+WZG0jYdBgWj8TLpvlBZqRjZp5NVxrewFWZLASEKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=Iz0Wx+wRxvSXTc88NjqAcwMkuHlRJOghwiucL3AFJTvlDynWtAcrNBpA+TDltpA+xrVJy2b1BYcLZMOU1r/pHXl3NJ0ZBr1eHifAIjPb2AOwxjx83th1FJQcppQH0H7fhqZyVpOg9+JP6+MKovGQcWKrxp9X1raAoCR18zscRhI=
Received: from SN6PR11MB2622.namprd11.prod.outlook.com (2603:10b6:805:57::31) by SN6PR11MB3375.namprd11.prod.outlook.com (2603:10b6:805:c0::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 15:39:01 +0000
Received: from SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a]) by SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a%7]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 15:39:01 +0000
From: "Jeffrey Ladouceur (jladouce)" <jladouce@cisco.com>
To: "Jeffrey Ladouceur (jladouce)" <jladouce=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Question about RFC 6242 : netconf over ssh
Thread-Index: AQHWParuaFqwbmDVr0iRhc3EpC4jhQ==
Date: Mon, 08 Jun 2020 15:39:01 +0000
Message-ID: <529EE682-F67A-4A04-A869-65882A895528@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [87.101.49.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5075512c-789d-4057-8c7a-08d80bc21180
x-ms-traffictypediagnostic: SN6PR11MB3375:
x-microsoft-antispam-prvs: <SN6PR11MB33758BC0936972DA377B0BAFDF850@SN6PR11MB3375.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6ujMr8rdg0S7wjQF7YUElxqOJC5TWfY9HZGgDbaL9Rsc++YVVe7rW2fkH2acIOZyz1xEjaQluk5Y1SEUkZHsj1xnjwyUUNj4K2svZhiB8sRx60mmL4VsDX8ch3fL8oYYK93c8Tj7nFmM7ifNUYqfZhhnSV5unTPsdmp72Gu8oQ3Q8QDBK/jbFMXlO3b7uPng1eoscAvfR1Iql0VfB0fD3yLVE6f0j6QlmN+53e+rIB75p+9tNYpielzp3dc9P/SiJ+C8Q5TeHTd7z/Z540BWvHT0eXpTLgkIH/P4Tx2YCtvdV2E6d1Og1ex2BE7KYAVjF5+Hl/mPrmzPL0/HRPkBtuvDa0Lfr9OP6i4oH7CEYupr2YxFz96Zgv4jou13NAtQB8ez/Mwi/NMOSfmU5SJvZQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2622.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(39860400002)(396003)(346002)(26005)(2616005)(6512007)(6486002)(86362001)(8676002)(36756003)(478600001)(186003)(316002)(76116006)(83380400001)(966005)(66946007)(91956017)(5660300002)(8936002)(66446008)(2906002)(110136005)(33656002)(71200400001)(6506007)(66476007)(64756008)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: TxPrkKo2Q+f+jgxa8WLAMZM7VG9bSvu2+//3Gd/XrQYMr1Nfk1LiThgI08uXkDFFMJuGEHv1db9iWSFMOyqzSeZrkkuB7k9I0gwFfpemnszOreMcjrhwKq25mnRvOXxD6NS8p00RLtyP94E/MnSMgc7t+3TbeQ/Pgd2DD4ezVMv0lrd8QmUL2eXTuFaNX2SgcAydGglk27AO2c7O3CMRB95+zTbi3SFLzB2N2Oo0BtZlTz/Z+xAtDr6x40fEn74cCjVDi0QfaZIedNE1O71Kk0wO+fMxbxdFedVzm8qE4WHWYdy9m5kLOW4PHghMgzHvIvdKPQhgBZgBln9U3Tk+Somx7/vN3otjTfDiU5tJt1n4ZnSiThEyToKmIlmiot/xJtaON2B9iAwhO5EmeV2t96hxySTXz/xtaDezwhe6ozBdWRRiVNfU8DMEMzyaHHzb6cHcnLLEo0yPC3REzymtHPn13nutVWf8TrUU07QjviU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <CE038335A1DF1344AF24B13CB6FD5328@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5075512c-789d-4057-8c7a-08d80bc21180
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 15:39:01.7233 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: k1Mkun+yeasOTj4cRtfJApTKPshtMVV9pq06m4u98kfCuf1Qj2Ppg8GaXM02ae6OzhX7TgSdVquaeF08sH9C5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3375
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KImZJ8VThcmMIxDTP4E5SSqNDbg>
Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh
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: Mon, 08 Jun 2020 15:39:11 -0000

Hello,

It's my understanding that running netconf over a pseudo terminal via ssh (i.e. pty-req) is most likely not a widely supported use-case as I don't see any refence to such use-case.

The pseudo terminal is typically used by an ssh client when the program on the server side expect to interreact with a terminal. To the best of my knowledge, a netconf server has no expectation, and in-fact may expect to be directly connected to the ssh server instance and not to a pty device.

Would it be reasonable for a netconf subsytem to sanitize its STDIN/STDOUT/STDERR and if they were attached to a tty to exit and drop the connection ?

Regards,
Jeffrey Ladouceur 

On 2020-05-07, 4:59 PM, "netconf on behalf of Jeffrey Ladouceur (jladouce)" <netconf-bounces@ietf.org on behalf of jladouce=40cisco.com@dmarc.ietf.org> wrote:

    Hello,

    I would like some input on a the following use-case and possible acceptable outcomes. 

    Summary:

    RFC 6242 doesn't explicitly indicate any lower level messaging in RFC 4254 which could "break" the netconf messaging between client and server.
    Specifically, the client can send a https://tools.ietf.org/html/rfc4254#section-6. "pty-req" just prior to invoking the "netconf" ssh subsystem.
    Having a pseudo-terminal device in between the client-server could result in the breakage of the messaging being client/server. 

    RFC 6242 states:
    https://tools.ietf.org/html/rfc6242#section-3 (Starting NECONF over SSH)

    1. Once the user has been successfully authenticated, the SSH client will invoke the "ssh-connection" service, also known as the SSH connection protocol.
    2. After the ssh-connection service is established, the SSH client will open a channel of type "session", which will result in an SSH session.
    3. Once the SSH session has been established, the NETCONF client will invoke NETCONF as an SSH subsystem called "netconf".
    4. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up.

    If I were to translate these steps into the corresponding RFC 4254 messages.

    Step (2) translates to:
    https://tools.ietf.org/html/rfc4254#section-6.1 (Opening a Session) , upon which a session has been established

    Step (3), this translates to https://tools.ietf.org/html/rfc4254#section-6.5 (Starting a Shell or a Command), but specifically the "subsystem" variant.
    With a string of “subsystem” and “subsystem name” set to netconf.

    Question:
    1- Does  RFC 6242 imply that it expects direct client/server connection without any interference from a pty device ? The text in item (4) appears to me to imply this.

    From what I can tell, the usage of this pty pattern is when a client wants netconf over tty.

    Thank you for any feedback.

    Regards,
    Jeff

    _______________________________________________
    netconf mailing list
    netconf@ietf.org
    https://www.ietf.org/mailman/listinfo/netconf