Network Working Group A. Okmianski
Request for Comments: 5426 Cisco Systems, Inc.
Category: Standards Track March 2009
Network Working Group A. Okmianski
Request for Comments: 5426 Cisco Systems, Inc.
Category: Standards Track March 2009
Transmission of Syslog Messages over UDP
通过UDP传输系统日志消息
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping.
本文档描述通过UDP/IPv4或UDP/IPv6传输系统日志消息。syslog协议分层体系结构支持任意数量的传输映射。但是，出于互操作性目的，需要syslog协议实现者支持此传输映射。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Transport Protocol ..............................................3
3.1. One Message Per Datagram ...................................3
3.2. Message Size ...............................................3
3.3. Source and Target Ports ....................................4
3.4. Source IP Address ..........................................4
3.5. UDP/IP Structure ...........................................4
3.6. UDP Checksums ..............................................4
4. Reliability Considerations ......................................5
4.1. Lost Datagrams .............................................5
4.2. Message Corruption .........................................5
4.3. Congestion Control .........................................5
4.4. Sequenced Delivery .........................................5
5. Security Considerations .........................................6
5.1. Sender Authentication and Message Forgery ..................6
5.2. Message Observation ........................................7
5.3. Replaying ..................................................7
5.4. Unreliable Delivery ........................................7
5.5. Message Prioritization and Differentiation .................7
5.6. Denial of Service ..........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Transport Protocol ..............................................3
3.1. One Message Per Datagram ...................................3
3.2. Message Size ...............................................3
3.3. Source and Target Ports ....................................4
3.4. Source IP Address ..........................................4
3.5. UDP/IP Structure ...........................................4
3.6. UDP Checksums ..............................................4
4. Reliability Considerations ......................................5
4.1. Lost Datagrams .............................................5
4.2. Message Corruption .........................................5
4.3. Congestion Control .........................................5
4.4. Sequenced Delivery .........................................5
5. Security Considerations .........................................6
5.1. Sender Authentication and Message Forgery ..................6
5.2. Message Observation ........................................7
5.3. Replaying ..................................................7
5.4. Unreliable Delivery ........................................7
5.5. Message Prioritization and Differentiation .................7
5.6. Denial of Service ..........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Informational RFC 3164 [8] describes the syslog protocol as it was observed in existing implementations. It describes both the format of syslog messages and a UDP [1] transport. Subsequently, a Standards-Track syslog protocol has been defined in RFC 5424 [2].
信息RFC 3164[8]描述了在现有实现中观察到的syslog协议。它描述了系统日志消息的格式和UDP[1]传输。随后，RFC 5424[2]中定义了标准跟踪系统日志协议。
RFC 5424 specifies a layered architecture that provides for support of any number of transport layer mappings for transmitting syslog messages. This document describes the UDP transport mapping for the syslog protocol.
RFC 5424指定了一个分层体系结构，该体系结构提供了对传输系统日志消息的任何数量的传输层映射的支持。本文档描述syslog协议的UDP传输映射。
The transport described in this document can be used for transmitting syslog messages over both IPv4 [3] and IPv6 [4].
本文档中描述的传输可用于通过IPv4[3]和IPv6[4]传输系统日志消息。
Network administrators and architects should be aware of the significant reliability and security issues of this transport, which stem from the use of UDP. They are documented in this specification. However, this transport is lightweight and is built upon the existing popular use of UDP for syslog.
网络管理员和架构师应该意识到这种传输的重大可靠性和安全性问题，这些问题源于UDP的使用。本规范中对其进行了记录。然而，这种传输是轻量级的，并且是建立在现有的普遍使用UDP for syslog的基础上的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
Each syslog UDP datagram MUST contain only one syslog message, which MAY be complete or truncated. The message MUST be formatted and truncated according to RFC 5424 [2]. Additional data MUST NOT be present in the datagram payload.
每个syslog UDP数据报必须仅包含一条syslog消息，该消息可以是完整的，也可以是截断的。必须根据RFC 5424[2]对消息进行格式化和截断。数据报有效负载中不得存在其他数据。
This transport mapping supports transmission of syslog messages up to 65535 octets minus the UDP header length. This limit stems from the maximum supported UDP size of 65535 octets specified in RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header because IPv4 has a 16-bit length field that also includes the header length.
此传输映射支持传输系统日志消息（最多65535个八位字节减去UDP标头长度）。此限制源于RFC 768[1]中指定的支持的最大UDP大小为65535个八位字节。对于IPv4，最大有效负载大小为65535个八位字节减去UDP报头，再减去IP报头，因为IPv4有一个16位长度字段，其中也包括报头长度。
IPv4 syslog receivers MUST be able to receive datagrams with message sizes up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message sizes up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with message sizes of up to and including 2048 octets. The ability to receive larger messages is encouraged.
IPv4系统日志接收器必须能够接收消息大小不超过480个八位字节的数据报。IPv6系统日志接收器必须能够接收消息大小不超过1180个八位字节的数据报。所有系统日志接收器应能够接收消息大小不超过2048个八位字节的数据报。鼓励接收较大信息的能力。
The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that Internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that conform to these limits have the greatest chance of being delivered because they do not require fragmentation.
上述限制和建议为互操作性建立了基线。所需的最小消息大小支持是根据Internet主机需要支持的最小MTU大小确定的：IPv4为576个八位字节[3]，IPv6为1280个八位字节[4]。符合这些限制的数据报最有可能被交付，因为它们不需要碎片。
It is RECOMMENDED that syslog senders restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use. This avoids datagram fragmentation and possible issues surrounding fragmentation such as incorrect MTU discovery.
建议系统日志发送者限制消息大小，使IP数据报不超过所用网络的最小MTU。这避免了数据报碎片和围绕碎片的可能问题，例如错误的MTU发现。
Fragmentation can be undesirable because it increases the risk of the message being lost due to loss of just one datagram fragment. Syslog has no acknowledgement facility, and therefore there is no effective way to handle retransmission. This makes it impossible for syslog to utilize packetization layer path MTU discovery [9]. When network MTU is not known in advance, the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6.
碎片可能是不可取的，因为它增加了由于仅丢失一个数据报碎片而丢失消息的风险。Syslog没有确认功能，因此没有处理重传的有效方法。这使得syslog无法利用打包层路径MTU发现[9]。当网络MTU事先未知时，最安全的假设是将消息限制为IPv4的480个八位字节和IPv6的1180个八位字节。
Syslog receivers MUST support accepting syslog datagrams on the well-known UDP port 514, but MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to the UDP port 514, but MAY be configurable to send messages to a different port. Syslog senders MAY use any source UDP port for transmitting messages.
Syslog接收器必须支持在众所周知的UDP端口514上接受Syslog数据报，但可以配置为在不同的端口上侦听。Syslog发送者必须支持将Syslog消息数据报发送到UDP端口514，但可以配置为将消息发送到其他端口。系统日志发送者可以使用任何源UDP端口来传输消息。
The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the syslog message. The entity sending the syslog message could be merely a relay. The syslog message itself contains the identifier of the originator of the message.
UDP数据报的源IP地址不应解释为发起syslog消息的主机的标识符。发送syslog消息的实体可能只是一个中继。syslog消息本身包含消息发起人的标识符。
Each UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in the UDP RFC 768 [1] and either the IPv4 RFC 791 [3] or IPv6 RFC 2460 [4], depending on which protocol is used.
传输层发送的每个UDP/IP数据报必须完全遵循UDP RFC 768[1]和IPv4 RFC 791[3]或IPv6 RFC 2460[4]中指定的结构，具体取决于使用的协议。
Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [4] mandates the use of UDP checksums when sending UDP datagrams over IPv6.
系统日志发送者不得禁用UDP校验和。IPv4系统日志发送者在发送消息时应使用UDP校验和。请注意，RFC 2460[4]要求在通过IPv6发送UDP数据报时使用UDP校验和。
Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums and SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [4] mandates the use of checksums for UDP over IPv6.
系统日志接收器不得禁用UDP校验和检查。IPv4系统日志接收器应检查UDP校验和，并应接受校验和为零的系统日志消息。请注意，RFC2460[4]要求在IPv6上对UDP使用校验和。
The UDP is an unreliable, low-overhead protocol. This section discusses reliability issues inherent in UDP that implementers and users should be aware of.
UDP是一种不可靠的低开销协议。本节讨论UDP固有的可靠性问题，实现者和用户应该注意这些问题。
This transport mapping does not provide any mechanism to detect and correct loss of datagrams. Datagrams can be lost in transit due to congestion, corruption, or any other intermittent network problem. IP fragmentation exacerbates this problem because loss of a single fragment will result in the entire message being discarded.
此传输映射不提供任何机制来检测和纠正数据报丢失。由于拥塞、损坏或任何其他间歇性网络问题，数据报可能在传输过程中丢失。IP碎片化加剧了这个问题，因为丢失单个碎片将导致整个消息被丢弃。
The UDP/IP datagrams can get corrupted in transit due to software, hardware, or network errors. This transport mapping specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols. However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message acknowledgement or retransmission mechanism.
由于软件、硬件或网络错误，UDP/IP数据报可能在传输过程中损坏。除了在IP和第2层协议中使用校验和外，此传输映射还指定使用UDP校验和来启用损坏检测。但是，校验和不能保证损坏检测，并且此传输映射不提供消息确认或重传机制。
Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [6]. This is why the syslog TLS transport [7] is REQUIRED to implement and RECOMMENDED for general use.
由于syslog可以生成无限量的数据，因此通过UDP传输这些数据通常是有问题的，因为UDP缺乏拥塞控制机制。拥塞控制机制通过降低流量率来应对拥塞，并在共享同一路径的流量之间建立一定程度的公平性，这对于互联网的稳定运行至关重要[6]。这就是为什么需要实现syslog TLS传输[7]，并推荐用于一般用途。
The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport [7] SHOULD be used.
syslog UDP传输可用作TLS传输的替代方案的唯一环境是托管网络，其中已通过流量工程机制（如速率限制或容量保留）为UDP syslog流量显式设置了网络路径。在所有其他环境中，应使用TLS传输[7]。
The IP transport used by the UDP does not guarantee that the sequence of datagram delivery will match the order in which the datagrams were sent. The time stamp contained within each syslog message can serve as a rough guide in establishing sequence order. However, it will not help in cases where multiple messages were generated during the
UDP使用的IP传输不能保证数据报的传递顺序与数据报的发送顺序相匹配。每个syslog消息中包含的时间戳可以作为建立序列顺序的粗略指南。但是，如果在测试过程中生成了多条消息，那么它将不会有帮助
same time slot, the sender could not generate a time stamp, or messages originated from different hosts whose clocks were not synchronized. The order of syslog message arrival via this transport SHOULD NOT be used as an authoritative guide in establishing an absolute or relative sequence of events on the syslog sender hosts.
在同一时间段内，发送方无法生成时间戳，或者消息来自时钟不同步的不同主机。在syslog发送方主机上建立绝对或相对事件序列时，不应将通过此传输到达syslog消息的顺序用作权威指南。
Using this specification on an unsecured network is NOT RECOMMENDED. Several syslog security considerations are discussed in RFC 5424 [2]. This section focuses on security considerations specific to the syslog transport over UDP. Some of the security issues raised in this section can be mitigated through the use of IPsec as defined in RFC 4301 [10].
不建议在不安全的网络上使用此规范。RFC 5424[2]中讨论了几个系统日志安全注意事项。本节重点介绍UDP上syslog传输的特定安全注意事项。本节中提出的一些安全问题可以通过使用RFC 4301[10]中定义的IPsec来缓解。
This transport mapping does not provide for strong sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or whether the packet was sent from another device. This can also lead to a case of mistaken identity if an inappropriately configured machine sends syslog messages to a receiver representing itself as another machine.
此传输映射不提供强发件人身份验证。syslog消息的接收者将无法确定消息是否确实是从报告的发送者发送的，或者数据包是否是从其他设备发送的。如果配置不当的机器将syslog消息发送给将自身表示为另一台机器的接收器，这也可能导致错误识别。
This transport mapping does not provide protection against syslog message forgery. An attacker can transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver.
此传输映射不提供防止系统日志消息伪造的保护。攻击者可以将系统日志消息（从据称发送消息的机器或任何其他机器）传输到接收方。
In one case, an attacker can hide the true nature of an attack amidst many other messages. As an example, an attacker can start generating forged messages indicating a problem on some machine. This can get the attention of the system administrators, who will spend their time investigating the alleged problem. During this time, the attacker could be able to compromise a different machine or a different process on the same machine.
在一种情况下，攻击者可以在许多其他消息中隐藏攻击的真实性质。例如，攻击者可以开始生成伪造消息，指示某台机器上存在问题。这会引起系统管理员的注意，他们会花时间调查所称的问题。在此期间，攻击者可能会破坏不同的机器或同一机器上的不同进程。
Additionally, an attacker can generate false syslog messages to give untrue indications of the status of systems. As an example, an attacker can stop a critical process on a machine, which could generate a notification of exit. The attacker can subsequently generate a forged notification that the process had been restarted. The system administrators could accept that misinformation and not verify that the process had indeed not been restarted.
此外，攻击者还可以生成虚假的系统日志消息，以提供不真实的系统状态指示。例如，攻击者可以停止计算机上的关键进程，从而生成退出通知。攻击者随后可以生成伪造的通知，表明进程已重新启动。系统管理员可以接受这一错误信息，而不验证进程是否确实没有重新启动。
This transport mapping does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is how they will be transferred. In most cases, passing clear-text, human-readable messages is a benefit to the administrators. Unfortunately, an attacker could also be able to observe the human-readable contents of syslog messages. The attacker could then use the knowledge gained from these messages to compromise a machine. It is RECOMMENDED that no sensitive information be transmitted via this transport mapping or that transmission of such information be restricted to properly secured networks.
此传输映射不提供传输中消息的机密性。如果系统日志消息是明文形式，则它们将以这种方式传输。在大多数情况下，传递明文、可读的消息对管理员来说是一种好处。不幸的是，攻击者还可以观察到系统日志消息的可读内容。然后，攻击者可以利用从这些消息中获得的知识来危害机器。建议不要通过此传输映射传输敏感信息，或将此类信息的传输限制在适当安全的网络上。
Message forgery and observation can be combined into a replay attack. An attacker could record a set of messages that indicate normal activity of a machine. At a later time, an attacker could remove that machine from the network and replay the syslog messages with new time stamps. The administrators could find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.
消息伪造和观察可以组合成重放攻击。攻击者可以记录一组指示计算机正常活动的消息。稍后，攻击者可以将该计算机从网络中删除，并使用新的时间戳重播系统日志消息。管理员在收到的消息中没有发现任何异常，收到这些消息将错误地指示机器的正常活动。
As was previously discussed in Section 4, Reliability Considerations, the UDP transport is not reliable, and packets containing syslog message datagrams can be lost in transit without any notice. There can be security consequences to the loss of one or more syslog messages. Administrators could be unaware of a developing and potentially serious problem. Messages could also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
正如前面在第4节“可靠性考虑”中所讨论的，UDP传输不可靠，包含syslog消息数据报的数据包在传输过程中可能会丢失，而不会发出任何通知。丢失一条或多条系统日志消息可能会带来安全后果。管理员可能不知道正在发展的潜在严重问题。攻击者还可以拦截和丢弃消息，以此隐藏未经授权的活动。
This transport mapping does not mandate prioritization of syslog messages either on the wire or when processed on the receiving host based on their severity. Unless some prioritization is implemented by sender, receiver, and/or network, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages.
此传输映射不要求根据系统日志消息的严重性在线路上或在接收主机上处理时对其进行优先级排序。除非发送方、接收方和/或网络实施某种优先级划分，否则此类行为的安全含义是系统日志接收方或网络设备可能会被低严重性消息淹没，并被迫丢弃潜在的高严重性消息。
An attacker could overwhelm a receiver by sending more messages to it than could be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat, such as optionally restricting reception of messages to a set of known source IP addresses.
攻击者可以通过向接收者发送比基础设施或设备本身所能处理的更多的消息来压倒接收者。实现者应该尝试提供将这种威胁降至最低的功能，例如选择性地将消息的接收限制在一组已知的源IP地址内。
This transport uses UDP port 514 for syslog, as recorded in the IANA port-numbers registry.
此传输使用IANA端口号注册表中记录的UDP端口514作为系统日志。
The author gratefully acknowledges the contributions of: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman, and all others who have commented on the various versions of this proposal.
作者衷心感谢克里斯·朗维克、雷纳·葛哈德斯、大卫·哈灵顿、安德鲁·罗斯、阿尔伯特·密特斯、伯尼·沃尔兹、米克尔·格雷厄姆、格雷格·莫里斯、亚历山德拉·费多洛娃、德文·科瓦奇、理查德·格雷文以及所有其他对本提案的不同版本发表评论的人的贡献。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[2] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[2] Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[6] Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.
[7] Miao，F.和Y.Ma，“系统日志的TLS传输映射”，RFC 54252009年3月。
[8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[8] Lonvick，C.，“BSD系统日志协议”，RFC 3164，2001年8月。
[9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[9] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[10] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[10] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
Author's Address
作者地址
Anton Okmianski Cisco Systems, Inc. 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada
安东·奥克米安斯基思科系统公司，地址：加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室V7X 1J1
Phone: +1-978-936-1612
EMail: aokmians@cisco.com
Phone: +1-978-936-1612
EMail: aokmians@cisco.com