idnits 2.17.1 draft-ietf-secsh-break-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '...length parameter SHOULD be ignored and...' RFC 2119 keyword, line 93: '... driver SHOULD be sent....' RFC 2119 keyword, line 97: '... is received, it SHOULD be processed a...' RFC 2119 keyword, line 102: '... a break of 500ms SHOULD be sent since...' RFC 2119 keyword, line 105: '... is 0, the break SHOULD be sent as 500...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 101 has weird spacing: '...nt. If break...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 19, 2003) is 7708 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 122, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 126, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-13 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-15 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-16 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Galbraith 3 Internet-Draft VanDyke Software 4 Expires: September 17, 2003 P. Remaker 5 Cisco Systems, Inc 6 March 19, 2003 8 Session Channel Break Extension 9 draft-ietf-secsh-break-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 17, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The Break Extension provides a way to send a break signal during a 40 SSH terminal session. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. The Break Request . . . . . . . . . . . . . . . . . . . . . . . 4 46 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 48 Intellectual Property and Copyright Statements . . . . . . . . . 6 50 1. Introduction 52 The SSH session channel provides a mechanism for the client-user to 53 interactively enter commands and receive output from a remote host 54 while taking advantage of the SSH transport's privacy and integrity 55 features. 57 A common application of the telnet protocol is the "Console Server" 58 whereby a telnet NVT can be connected to a physical RS-232/V.24 59 asynchronous port, allowing the telnet NVT to appear as a locally 60 attached terminal to that port, and allowing that port to appear as a 61 network addressable device. A number of major computer equipment 62 vendors provide high level administrative functions through an 63 asynchronous serial port and generally expect the attached terminal 64 to be capable of send a BREAK signal, which is defined as the TxD 65 signal being held in a SPACE state for a time greater than a whole 66 character time, typically interpreted as 250 to 500 ms. 68 The telnet protocolprovides a means to send a "BREAK" signal, which 69 is defined as a "a signal outside the USASCII set which is currently 70 given local meaning within many systems." [1] Console Server vendors 71 interpret the TELNET break signal as a physical break signal, which 72 can then allow access to the full range of administartive functions 73 available on an asynchronous serial console port. 75 The lack of a similar facility in the SSH session channel has forced 76 users to continue the use of telnet for the "Console Server" 77 function. 79 2. The Break Request 81 The following following channel specific request can be sent to 82 request that the remote host perform a break operation. 84 byte SSH_MSG_CHANNEL_REQUEST 85 uint32 recipient channel 86 string "break" 87 boolean want_reply 88 uint32 break-length in milliseconds 90 If the break length cannot be controlled by the application receiving 91 this request, the break length parameter SHOULD be ignored and the 92 default break signal length of the chipset or underlying chipset 93 driver SHOULD be sent. 95 If the application can control the break-length, the following 96 suggestions are made reagarding break duration. If a break duration 97 request of greater than 3000ms is received, it SHOULD be processed as 98 a 3000ms break, in order to an unreasonably long break request 99 causing the port to become unavailable for as long as 47 days while 100 executing the break. Applications that require a longer break may 101 choose to ignore this requirement. If break duration request of 102 less than 500ms, is requested a break of 500ms SHOULD be sent since 103 most devices will recognize a break of that length. In the event 104 that an application needs a shorter break, this can be ignored. If 105 the break-length parameter is 0, the break SHOULD be sent as 500ms or 106 the default break signal length of the chipset or underlying chipset 107 driver . 109 If the want_reply boolean is set, the server MUST reply using 110 SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [4] messages. If 111 a break of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be 112 sent. If no break was preformed, SSH_MSG_CHANNEL_FAILURE MUST be 113 sent. 115 This operation SHOULD be support by most general purpose SSH clients. 117 References 119 [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 120 8, RFC 854, May 1983. 122 [2] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 123 Protocol Architecture", draft-ietf-secsh-architecture-13 (work 124 in progress), September 2002. 126 [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. 127 Lehtinen, "SSH Transport Layer Protocol", 128 draft-ietf-secsh-transport-15 (work in progress), September 129 2002. 131 [4] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 132 Connection Protocol", draft-ietf-secsh-connect-16 (work in 133 progress), September 2002. 135 Authors' Addresses 137 Joseph Galbraith 138 VanDyke Software 139 4848 Tramway Ridge Blvd 140 Suite 101 141 Albuquerque, NM 87111 142 US 144 Phone: +1 505 332 5700 145 EMail: galb-list@vandyke.com 147 Phillip Remaker 148 Cisco Systems, Inc 149 170 West Tasman Drive 150 San Jose, CA 95120 151 US 153 EMail: remaker@cisco.com 155 Intellectual Property Statement 157 The IETF takes no position regarding the validity or scope of any 158 intellectual property or other rights that might be claimed to 159 pertain to the implementation or use of the technology described in 160 this document or the extent to which any license under such rights 161 might or might not be available; neither does it represent that it 162 has made any effort to identify any such rights. Information on the 163 IETF's procedures with respect to rights in standards-track and 164 standards-related documentation can be found in BCP-11. Copies of 165 claims of rights made available for publication and any assurances of 166 licenses to be made available, or the result of an attempt made to 167 obtain a general license or permission for the use of such 168 proprietary rights by implementors or users of this specification can 169 be obtained from the IETF Secretariat. 171 The IETF invites any interested party to bring to its attention any 172 copyrights, patents or patent applications, or other proprietary 173 rights which may cover technology that may be required to practice 174 this standard. Please address the information to the IETF Executive 175 Director. 177 Full Copyright Statement 179 Copyright (C) The Internet Society (2003). All Rights Reserved. 181 This document and translations of it may be copied and furnished to 182 others, and derivative works that comment on or otherwise explain it 183 or assist in its implementation may be prepared, copied, published 184 and distributed, in whole or in part, without restriction of any 185 kind, provided that the above copyright notice and this paragraph are 186 included on all such copies and derivative works. However, this 187 document itself may not be modified in any way, such as by removing 188 the copyright notice or references to the Internet Society or other 189 Internet organizations, except as needed for the purpose of 190 developing Internet standards in which case the procedures for 191 copyrights defined in the Internet Standards process must be 192 followed, or as required to translate it into languages other than 193 English. 195 The limited permissions granted above are perpetual and will not be 196 revoked by the Internet Society or its successors or assignees. 198 This document and the information contained herein is provided on an 199 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 200 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 201 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 202 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 203 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 205 Acknowledgement 207 Funding for the RFC Editor function is currently provided by the 208 Internet Society.