The Secure Shell (SSH) Protocol Architecture
RFC 4251
| Document | Type | RFC - Proposed Standard (January 2006) | |
|---|---|---|---|
| Authors | Chris M. Lonvick , Tatu Ylonen | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Russ Housley | |
| Send notices to | (None) |
RFC 4251
CCAMP Working Group J. Ahlberg
Internet-Draft Ericsson AB
Intended status: Standards Track M. Ye
Expires: June 1, 2019 Huawei Technologies
X. Li
NEC Laboratories Europe
D. Spreafico
Nokia - IT
M. Vaupotic
Aviat Networks
November 28, 2018
A YANG Data Model for Microwave Radio Link
draft-ietf-ccamp-mw-yang-13
Abstract
This document defines a YANG data model for control and management of
the radio link interfaces, and their connectivity to packet
(typically Ethernet) interfaces in a microwave/millimeter wave node.
The data nodes for management of the interface protection
functionality is broken out into a separate and generic YANG data
model in order to make it available also for other interface types.
RFC Ed. Note
// RFC Ed.: replace all XXXX throughout the document with actual RFC
numbers and remove this note
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2019.
Ahlberg, et al. Expires June 1, 2019 [Page 1]
Internet-Draft Microwave YANG Model November 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
1.2. Tree Structure . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Microwave Radio Link YANG Data Model . . . . . . . . . . . . 5
3.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Explanation of the Microwave Data Model . . . . . . . . . 7
4. Microwave Radio Link YANG Module . . . . . . . . . . . . . . 7
5. Interface Protection YANG Module . . . . . . . . . . . . . . 27
6. Microwave Types YANG Module . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example: 1+0 and 2+0 configuration instances . . . . 45
A.1. 1+0 instance . . . . . . . . . . . . . . . . . . . . . . 46
A.2. 2+0 instance . . . . . . . . . . . . . . . . . . . . . . 47
A.3. 2+0 XPIC instance . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction
This document defines a YANG data model for management and control of
the radio link interface(s) and the relationship to packet (typically
Ethernet) and/or TDM interfaces in a microwave/millimeter wave node.
ETSI EN 302 217 series defines the characteristics and requirements
of microwave/millimeter wave equipment and antennas. Especially ETSI
EN 302 217-2 [EN302217-2] specifies the essential parameters for the
systems operating from 1.4GHz to 86GHz. The data model includes
Ahlberg, et al. Expires June 1, 2019 [Page 2]
Internet-Draft Microwave YANG Model November 2018
configuration and state data according to the new Network Management
Datastore Architecture [RFC8342].
The design of the data model follows the framework for management and
control of microwave and millimeter wave interface parameters defined
in [RFC8432]. This framework identifies the need and the scope of
the YANG data model, the use cases and requirements that the model
needs to support. Moreover, it provides a detailed gap analysis to
identify the missing parameters and functionalities of the existing
and established models to support the specified use cases and
requirements, and based on that recommends how the gaps should be
filled with the development of the new model. According to the
conclusion of the gap analysis, the structure of the data model is
based on the structure defined in
[I-D.ahlberg-ccamp-microwave-radio-link] and it augments [RFC8343] to
align with the same structure for management of the packet
interfaces. More specifically, the model will include interface
layering to manage the capacity provided by a radio link terminal for
the associated Ethernet and TDM interfaces, using the principles for
interface layering described in [RFC8343] as a basis.
The data nodes for management of the interface protection
functionality is broken out into a separate and generic YANG data
module in order to make it available also for other interface types.
The designed YANG data model uses established microwave equipment and
radio standards, such as ETSI EN 302 217-2, and the IETF: Radio Link
Model [I-D.ahlberg-ccamp-microwave-radio-link] and the ONF: Microwave
Modeling [ONF-model] as the basis for the definition of the detailed
leafs/parameters, and proposes new ones to cover identified gaps
which are analyzed in [RFC8432].
1.1. Terminology and Definitions
The following terms are used in this document:
Carrier Termination (CT) is an interface for the capacity provided
over the air by a single carrier. It is typically defined by its
transmitting and receiving frequencies.
Radio Link Terminal (RLT) is an interface providing packet capacity
and/or TDM capacity to the associated Ethernet and/or TDM interfaces
in a node and used for setting up a transport service over a
microwave/millimeter wave link.
The following acronyms are used in this document:
ACM Adaptive Coding Modulation
Ahlberg, et al. Expires June 1, 2019 [Page 3]
Internet-Draft Microwave YANG Model November 2018
ATPC Automatic Transmit Power Control
BBE Background Block Errors
BER Bit Error Ratio
BPSK Binary Phase-Shift Keying
CM Coding Modulation
CT Carrier Termination
ES Errored Seconds
IF Intermediate Frequency
MIMO Multiple-Input Multiple-Output
RF Radio Frequency
RLT Radio Link Terminal
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase-Shift Keying
RTPC Remote Transmit Power Control
SES Severely Errored Seconds
TDM Time-Division Multiplexing
UAS Unavailable Seconds
XPIC Cross Polarization Interference Cancellation
1.2. Tree Structure
A simplified graphical representation of the data model is used in
chapter 3.1 of this this document. The meaning of the symbols in
these diagrams is defined in [RFC8340].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
Ahlberg, et al. Expires June 1, 2019 [Page 4]
Internet-Draft Microwave YANG Model November 2018
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Microwave Radio Link YANG Data Model
3.1. YANG Tree
module: ietf-microwave-radio-link
+--rw radio-link-protection-groups
| +--rw protection-group* [name]
| +--rw name string
| +--rw protection-architecture-type? identityref
| +--rw members* if:interface-ref
| +--rw operation-type? enumeration
| +--rw working-entity* if:interface-ref
| +--rw revertive-wait-to-restore? uint16
| +--rw hold-off-timer? uint16
| +--ro status? identityref
| +---x manual-switch-working
| +---x manual-switch-protection
| +---x forced-switch
| +---x lockout-of-protection
| +---x freeze
| +---x exercise
| +---x clear
+--rw xpic-pairs {xpic}?
| +--rw xpic-pair* [name]
| +--rw name string
| +--rw enabled? boolean
| +--rw members* if:interface-ref
+--rw mimo-groups {mimo}?
+--rw mimo-group* [name]
+--rw name string
+--rw enabled? boolean
+--rw members* if:interface-ref
augment /if:interfaces/if:interface:
+--rw id? string
+--rw mode identityref
+--rw carrier-terminations* if:interface-ref
+--rw rlp-groups*
| -> /radio-link-protection-groups/protection-group/name
+--rw xpic-pairs* -> /xpic-pairs/xpic-pair/name
| {xpic}?
+--rw mimo-groups* -> /mimo-groups/mimo-group/name
| {mimo}?
+--rw tdm-connections* [tdm-type] {tdm}?
+--rw tdm-type identityref
Ahlberg, et al. Expires June 1, 2019 [Page 5]
Internet-Draft Microwave YANG Model November 2018
+--rw tdm-connections uint16
augment /if:interfaces/if:interface:
+--rw carrier-id? string
+--rw tx-enabled? boolean
+--ro tx-oper-status? enumeration
+--rw tx-frequency uint32
+--rw (freq-or-distance)
| +--:(rx-frequency)
| | +--rw rx-frequency? uint32
| +--:(duplex-distance)
| +--rw duplex-distance? int32
+--ro actual-rx-frequency? uint32
+--ro actual-duplex-distance? uint32
+--rw channel-separation uint32
+--rw polarization? enumeration
+--rw (power-mode)
| +--:(rtpc)
| | +--rw rtpc
| | +--rw maximum-nominal-power power
| +--:(atpc)
| +--rw atpc
| +--rw maximum-nominal-power power
| +--rw atpc-lower-threshold power
| +--rw atpc-upper-threshold power
+--ro actual-transmitted-level? power
+--ro actual-received-level? power
+--rw (coding-modulation-mode)
| +--:(single)
| | +--rw single
| | +--rw selected-cm identityref
| +--:(adaptive)
| +--rw adaptive
| +--rw selected-min-acm identityref
| +--rw selected-max-acm identityref
+--ro actual-tx-cm? identityref
+--ro actual-snir? decimal64
+--ro actual-xpi? decimal64 {xpic}?
+--rw ct-performance-thresholds
| +--rw received-level-alarm-threshold? power
| +--rw transmitted-level-alarm-threshold? power
| +--rw ber-alarm-threshold? enumeration
+--rw if-loop? enumeration
+--rw rf-loop? enumeration
+--ro capabilities
| +--ro min-tx-frequency? uint32
| +--ro max-tx-frequency? uint32
| +--ro min-rx-frequency? uint32
| +--ro max-rx-frequency? uint32
Ahlberg, et al. Expires June 1, 2019 [Page 6]
Internet-Draft Microwave YANG Model November 2018
| +--ro minimum-power? power
| +--ro maximum-available-power? power
| +--ro available-min-acm? identityref
| +--ro available-max-acm? identityref
+--ro error-performance-statistics
| +--ro bbe? yang:counter32
| +--ro es? yang:counter32
| +--ro ses? yang:counter32
| +--ro uas? yang:counter32
+--ro radio-performance-statistics
+--ro min-rltm? power
+--ro max-rltm? power
+--ro min-tltm? power
+--ro max-tltm? power
3.2. Explanation of the Microwave Data Model
The leafs in the Interface Management Module augmented by Radio Link
Terminal (RLT) and Carrier Termination (CT) are not always
applicable.
"/interfaces/interface/enabled" is not applicable for RLT. Enable
and disable of an interface is done in the constituent CTs.
The packet related measurements "in-octets", "in-unicast-pkts", "in-
broadcast-pkts", "in-multicast-pkts", "in-discards", "in-errors",
"in-unknown-protos", "out-octets", "out-unicast-pkts", "out-
broadcast-pkts", "out-multicast-pkts", "out-discards", "out-errors"
are not within the scope of the microwave radio link domain and
therefore not applicable for RLT and CT.
4. Microwave Radio Link YANG Module
This module imports typedefs and modules from [RFC6991], [RFC8343]
and [RFC7224], and it references [TR102311], [EN302217-1],
[EN301129], and [G.826].
<CODE BEGINS> file "ietf-microwave-radio-link@2018-11-28.yang"
module ietf-microwave-radio-link {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link";
prefix mrl;
import ietf-yang-types {
prefix yang;
Ahlberg, et al. Expires June 1, 2019 [Page 7]
Internet-Draft Microwave YANG Model November 2018
reference "RFC 6991";
}
import iana-if-type {
prefix ianaift;
}
import ietf-interfaces {
prefix if;
reference "RFC 8343";
}
import ietf-interface-protection {
prefix ifprot;
reference "RFC XXXX";
}
import ietf-microwave-types {
prefix mw-types;
reference "RFC XXXX";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"WG List: <mailto:ccamp@ietf.org>
ID-draft editors:
// RFC Ed.: replace ID-draft editors with Editors and remove
// this note
Jonas Ahlberg (jonas.ahlberg@ericsson.com);
Min Ye (amy.yemin@huawei.com);
Xi Li (Xi.Li@neclab.eu);
Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description
"This is a module for the entities in
a generic microwave system.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
Ahlberg, et al. Expires June 1, 2019 [Page 8]
Internet-Draft Microwave YANG Model November 2018
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.";
revision 2018-11-28 {
description "Initial revision.";
reference "RFC XXXX: A YANG Data Model for Microwave Radio Link";
}
/*
* Features
*/
feature xpic {
description
"Indicates that the device supports XPIC.";
reference "ETSI TR 102 311";
}
feature mimo {
description
"Indicates that the device supports MIMO.";
reference "ETSI TR 102 311";
}
feature tdm {
description
"Indicates that the device supports TDM.";
}
/*
* Typedefs
*/
typedef power {
type decimal64 {
fraction-digits 1;
}
description
"Type used for power values, selected and measured.";
}
/*
* Radio Link Terminal (RLT)
Ahlberg, et al. Expires June 1, 2019 [Page 9]
Internet-Draft Microwave YANG Model November 2018
*/
augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type,"
+ "'ianaift:radio-link-terminal')";
description
"Addition of data nodes for radio link terminal to
the standard Interface data model, for interfaces of
the type 'radio-link-terminal'.";
leaf id {
type string;
description
"Descriptive identity of the radio link terminal used by
far-end RLT to check that it's connected to the correct
near-end RLT. Does not need to be configured if this check
is not used.";
}
leaf mode {
type identityref {
base mw-types:rlt-mode;
}
mandatory true;
description
"A description of the mode in which the radio link
terminal is configured. The format is X plus Y.
X represent the number of bonded carrier terminations.
Y represent the number of protecting carrier
terminations.";
}
leaf-list carrier-terminations {
type if:interface-ref;
must "derived-from-or-self(/if:interfaces/if:interface"
+ "[if:name = current()]"
+ "/if:type, 'ianaift:carrier-termination')" {
description
"The type of interface must be
'carrier-termination'.";
}
min-elements 1;
description
"A list of references to carrier terminations
included in the radio link terminal.";
}
leaf-list rlp-groups {
Ahlberg, et al. Expires June 1, 2019 [Page 10]
Internet-Draft Microwave YANG Model November 2018
type leafref {
path "/mrl:radio-link-protection-groups/"
+ "mrl:protection-group/mrl:name";
}
description
"A list of references to the carrier termination
groups configured for radio link protection in this
radio link terminal.";
}
leaf-list xpic-pairs {
if-feature xpic;
type leafref {
path "/mrl:xpic-pairs/mrl:xpic-pair/mrl:name";
}
description
"A list of references to the XPIC pairs used in this
radio link terminal. One pair can be used by two
terminals.";
reference "ETSI TR 102 311";
}
leaf-list mimo-groups {
if-feature mimo;
type leafref {
path "/mrl:mimo-groups/mrl:mimo-group/mrl:name";
}
description
"A reference to the MIMO group used in this
radio link terminal. One group can be used by more
than one terminal.";
reference "ETSI TR 102 311";
}
list tdm-connections {
if-feature tdm;
key "tdm-type";
description
"A list stating the number of active TDM connections
of a specified tdm-type that is configured to be
supported by the RLT.";
leaf tdm-type {
type identityref {
base mw-types:tdm-type;
}
description
"The type of TDM connection, which also indicates
Ahlberg, et al. Expires June 1, 2019 [Page 11]
Internet-Draft Microwave YANG Model November 2018
the supported capacity.";
}
leaf tdm-connections {
type uint16;
mandatory true;
description
"Number of connections of the specified type.";
}
}
}
/*
* Carrier Termination
*/
augment "/if:interfaces/if:interface" {
when "derived-from-or-self(if:type,"
+ "'ianaift:carrier-termination')";
description
"Addition of data nodes for carrier termination to
the standard Interface data model, for interfaces
of the type 'carrier-termination'.";
leaf carrier-id {
type string;
default "A";
description
"ID of the carrier. (e.g. A, B, C or D)
Used in XPIC & MIMO configurations to check that
the carrier termination is connected to the correct
far-end carrier termination. Should be the same
carrier ID on both sides of the hop.
Left as default value when MIMO and XPIC are not in use.";
}
leaf tx-enabled {
type boolean;
default "false";
description
"Disables (false) or enables (true) the transmitter.
Only applicable when the interface is enabled
(interface:enabled = true) otherwise it's always
disabled.";
}
leaf tx-oper-status {
type enumeration {
Ahlberg, et al. Expires June 1, 2019 [Page 12]
Internet-Draft Microwave YANG Model November 2018
enum "off" {
description "Transmitter is off.";
}
enum "on" {
description "Transmitter is on.";
}
enum "standby" {
description "Transmitter is in standby.";
}
}
config false;
description
"Shows the operative status of the transmitter.";
}
leaf tx-frequency {
type uint32;
units "kHz";
mandatory true;
description
"Selected transmitter frequency.";
}
choice freq-or-distance {
leaf rx-frequency {
type uint32;
units "kHz";
description
"Selected receiver frequency.";
}
leaf duplex-distance {
type int32;
units "kHz";
description
"Distance between transmitter and receiver frequencies.";
}
mandatory true;
description
"A choice to configure rx-frequency directly or by computing
it as duplex-distance subtracted from tx-frequency." ;
}
leaf actual-rx-frequency {
type uint32;
units "kHz";
config false;
description
"Computed receiver frequency.";
Ahlberg, et al. Expires June 1, 2019 [Page 13]
Internet-Draft Microwave YANG Model November 2018
}
leaf actual-duplex-distance {
type uint32;
units "kHz";
config false;
description
"Computed distance between Tx & Rx frequencies.";
}
leaf channel-separation {
type uint32;
units "kHz";
mandatory true;
description
"The amount of bandwidth allocated to a carrier. The distance
between adjacent channels in a radio frequency channels
arrangement";
reference "ETSI EN 302 217-1";
}
leaf polarization {
type enumeration {
enum "horizontal" {
description "Horizontal polarization.";
}
enum "vertical" {
description "Vertical polarization.";
}
enum "not-specified" {
description "Polarization not specified.";
}
}
default "not-specified";
description
"Polarization - A textual description for info only.";
}
choice power-mode {
container rtpc {
description
"Remote Transmit Power Control (RTPC).";
reference "ETSI EN 302 217-1";
leaf maximum-nominal-power {
type power {
range "-99..99";
}
Ahlberg, et al. Expires June 1, 2019 [Page 14]
Internet-Draft Microwave YANG Model November 2018
units "dBm";
mandatory true;
description
"Selected output power.";
reference "ETSI EN 302 217-1";
}
}
container atpc {
description
"Automatic Transmit Power Control (ATPC).";
reference "ETSI EN 302 217-1";
leaf maximum-nominal-power {
type power {
range "-99..99";
}
units "dBm";
mandatory true;
description
"Selected maximum output power. Minimum output
power is the same as the system capability,
available-min-output-power.";
reference "ETSI EN 302 217-1";
}
leaf atpc-lower-threshold {
type power {
range "-99..-20";
}
units "dBm";
must "current() <= ../atpc-upper-threshold";
mandatory true;
description
"The lower threshold for the input power at far-end
used in the ATPC mode.";
reference "ETSI EN 302 217-1";
}
leaf atpc-upper-threshold {
type power {
range "-99..-20";
}
units "dBm";
mandatory true;
description
"The upper threshold for the input power at far-end
used in the ATPC mode.";
reference "ETSI EN 302 217-1";
Ahlberg, et al. Expires June 1, 2019 [Page 15]
Internet-Draft Microwave YANG Model November 2018
}
}
mandatory true;
description
"A choice of Remote Transmit Power Control (RTPC)
or Automatic Transmit Power Control (ATPC).";
}
leaf actual-transmitted-level {
type power {
range "-99..99";
}
units "dBm";
config false;
description
"Actual transmitted power level (0.1 dBm resolution).";
reference "ETSI EN 301 129";
}
leaf actual-received-level {
type power {
range "-99..-20";
}
units "dBm&9.5. Connection Protocol
9.5.1. End Point Security
End point security is assumed by the connection protocol. If the
server has been compromised, any terminal sessions, port forwarding,
or systems accessed on the host are compromised. There are no
mitigating factors for this.
If the client has been compromised, and the server fails to stop the
attacker at the authentication protocol, all services exposed (either
as subsystems or through forwarding) will be vulnerable to attack.
Implementers SHOULD provide mechanisms for administrators to control
which services are exposed to limit the vulnerability of other
services. These controls might include controlling which machines
and ports can be targeted in port-forwarding operations, which users
are allowed to use interactive shell facilities, or which users are
allowed to use exposed subsystems.
9.5.2. Proxy Forwarding
The SSH connection protocol allows for proxy forwarding of other
protocols such as SMTP, POP3, and HTTP. This may be a concern for
network administrators who wish to control the access of certain
applications by users located outside of their physical location.
Essentially, the forwarding of these protocols may violate site-
specific security policies, as they may be undetectably tunneled
through a firewall. Implementers SHOULD provide an administrative
mechanism to control the proxy forwarding functionality so that
site-specific security policies may be upheld.
In addition, a reverse proxy forwarding functionality is available,
which, again, can be used to bypass firewall controls.
As indicated above, end-point security is assumed during proxy
forwarding operations. Failure of end-point security will compromise
all data passed over proxy forwarding.
9.5.3. X11 Forwarding
Another form of proxy forwarding provided by the SSH connection
protocol is the forwarding of the X11 protocol. If end-point
security has been compromised, X11 forwarding may allow attacks
against the X11 server. Users and administrators should, as a matter
of course, use appropriate X11 security mechanisms to prevent
unauthorized use of the X11 server. Implementers, administrators,
and users who wish to further explore the security mechanisms of X11
are invited to read [SCHEIFLER] and analyze previously reported
Ylonen & Lonvick Standards Track [Page 24]
RFC 4251 SSH Protocol Architecture January 2006
problems with the interactions between SSH forwarding and X11 in CERT
vulnerabilities VU#363181 and VU#118892 [CERT].
X11 display forwarding with SSH, by itself, is not sufficient to
correct well known problems with X11 security [VENEMA]. However, X11
display forwarding in SSH (or other secure protocols), combined with
actual and pseudo-displays that accept connections only over local
IPC mechanisms authorized by permissions or access control lists
(ACLs), does correct many X11 security problems, as long as the
"none" MAC is not used. It is RECOMMENDED that X11 display
implementations default to allow the display to open only over local
IPC. It is RECOMMENDED that SSH server implementations that support
X11 forwarding default to allow the display to open only over local
IPC. On single-user systems, it might be reasonable to default to
allow the local display to open over TCP/IP.
Implementers of the X11 forwarding protocol SHOULD implement the
magic cookie access-checking spoofing mechanism, as described in
[SSH-CONNECT], as an additional mechanism to prevent unauthorized use
of the proxy.
Ylonen & Lonvick Standards Track [Page 25]
RFC 4251 SSH Protocol Architecture January 2006
10. References
10.1. Normative References
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Connection Protocol", RFC 4254, January
2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure
Shell (SSH) Protocol Assigned Numbers", RFC 4250,
January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
10.2. Informative References
[RFC0822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
Ylonen & Lonvick Standards Track [Page 26]
RFC 4251 SSH Protocol Architecture January 2006
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
"The Kerberos Network Authentication Service
(V5)", RFC 4120, July 2005.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API
Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP
Authentication with Replay Prevention", RFC 2085,
February 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC
2104, February 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption
Algorithm and Its Use With IPsec", RFC 2410,
November 1998.
[RFC2743] Linn, J., "Generic Security Service Application
Program Interface Version 2, Update 1", RFC 2743,
January 2000.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths
For Public Keys Used For Exchanging Symmetric
Keys", BCP 86, RFC 3766, April 2004.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[FIPS-180-2] US National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-2, August
2002.
[FIPS-186-2] US National Institute of Standards and Technology,
"Digital Signature Standard (DSS)", Federal
Information Processing Standards Publication 186-
2, January 2000.
Ylonen & Lonvick Standards Track [Page 27]
RFC 4251 SSH Protocol Architecture January 2006
[FIPS-197] US National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", Federal
Information Processing Standards Publication 197,
November 2001.
[ANSI-T1.523-2001] American National Standards Institute, Inc.,
"Telecom Glossary 2000", ANSI T1.523-2001,
February 2001.
[SCHNEIER] Schneier, B., "Applied Cryptography Second
Edition: protocols algorithms and source in code
in C", John Wiley and Sons, New York, NY, 1996.
[SCHEIFLER] Scheifler, R., "X Window System : The Complete
Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
edition.", Digital Press, ISBN 1555580882,
February 1992.
[KAUFMAN] Kaufman, C., Perlman, R., and M. Speciner,
"Network Security: PRIVATE Communication in a
PUBLIC World", Prentice Hall Publisher, 1995.
[CERT] CERT Coordination Center, The.,
"http://www.cert.org/nav/index_red.html".
[VENEMA] Venema, W., "Murphy's Law and Computer Security",
Proceedings of 6th USENIX Security Symposium, San
Jose CA
http://www.usenix.org/publications/library/
proceedings/sec96/venema.html, July 1996.
[ROGAWAY] Rogaway, P., "Problems with Proposed IP
Cryptography", Unpublished paper
http://www.cs.ucdavis.edu/~rogaway/ papers/draft-
rogaway-ipsec-comments-00.txt, 1996.
[DAI] Dai, W., "An attack against SSH2 protocol", Email
to the SECSH Working Group ietf-ssh@netbsd.org
ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002-
02.mail, Feb 2002.
[BELLARE] Bellaire, M., Kohno, T., and C. Namprempre,
"Authenticated Encryption in SSH: Fixing the SSH
Binary Packet Protocol", Proceedings of the 9th
ACM Conference on Computer and Communications
Security, Sept 2002.
Ylonen & Lonvick Standards Track [Page 28]
RFC 4251 SSH Protocol Architecture January 2006
[Openwall] Solar Designer and D. Song, "SSH Traffic Analysis
Attacks", Presentation given at HAL2001 and
NordU2002 Conferences, Sept 2001.
[USENIX] Song, X.D., Wagner, D., and X. Tian, "Timing
Analysis of Keystrokes and SSH Timing Attacks",
Paper given at 10th USENIX Security Symposium,
2001.
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Valimotie 17
00380 Helsinki
Finland
EMail: ylo@ssh.com
Chris Lonvick (editor)
Cisco Systems, Inc.
12515 Research Blvd.
Austin 78759
USA
EMail: clonvick@cisco.com
Trademark Notice
"ssh" is a registered trademark in the United States and/or other
countries.
Ylonen & Lonvick Standards Track [Page 29]
RFC 4251 SSH Protocol Architecture January 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ylonen & Lonvick Standards Track [Page 30]