Internet Engineering Task Force Z. Chen Internet-Draft China Telecom Intended status: Informational C. Zhou Expires: January 4, 2013 Huawei Technologies T. Tsou Huawei Technologies (USA) July 3, 2012 The Syslog Requirements to Support NAT Log in Traceback Solutions draft-zhou-behave-syslog-nat-logging-00 Abstract This document describes the syslog information that are required for NAT logging. The document will define the NAT logging server which supports traceback and explain the procedure of network location and service support for traceback. The requirements of syslog interface and Radius interface to support NAT log are introduced. 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 http://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 January 4, 2013. Copyright Notice Copyright (c) 2012 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 (http://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 Chen, et al. Expires January 4, 2013 [Page 1] Internet-Draft Syslog Requirements for NAT Log July 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Traceback Solutions . . . . . . . . . . . . . . . . . . . 3 1.2. The Log Server Function . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Requirements of Log Server Function . . . . . . . . . . . 4 4. The Log Server Interface Requirements . . . . . . . . . . . . 5 4.1. Syslog Interface . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Definition of HEADER Part . . . . . . . . . . . . . . 5 4.1.1.1. PRI . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1.2. VERSION . . . . . . . . . . . . . . . . . . . . . 7 4.1.1.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . 7 4.1.1.4. HOSTNAME . . . . . . . . . . . . . . . . . . . . . 7 4.1.1.5. APP-NAME . . . . . . . . . . . . . . . . . . . . . 7 4.1.1.6. PROCID . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1.7. MSGID . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Definition of MSG Part . . . . . . . . . . . . . . . . 8 4.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. The Radius Interface Requirements . . . . . . . . . . . . 9 5. The Performance Requirements of The Log Server . . . . . . . . 10 6. The Reliability Requirements of The Log Server . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Chen, et al. Expires January 4, 2013 [Page 2] Internet-Draft Syslog Requirements for NAT Log July 2012 1. Introduction 1.1. Traceback Solutions In the existing IPv6 transition technology, there are two ways of address and port mapping:static mapping and dynamic mapping. Based on this, we summarize four traceback solutions: 1. After the address and port mapping information is created, NAT device (e.g.,Carrier Grade NAT) sends the syslog mapping information to the log server. AAA system acquires the dynamic address mapping information from the syslog server when receiving traceback request. 2. NAT device reports the dynamic mapping information to AAA system via radius protocol. AAA system will record the subscriber online information and source session list. After traceback request is received, AAA system will return the trackback result with the subscriber online information and source session list information. 3. NAT device reports the dynamic mapping information to the log server through radius protocol. AAA system acquires the mapping information from syslog server when receiving the traceback request. 4. AAA system and NAT device send the parameters through network configuration system and perform the same mapping algorithm to generate address and port. In the traceback procedure, there is no need for AAA system and NAT device to transmit the mapping information. In solution 1 and 3, the traceback log server will be a newly created device. 1.2. The Log Server Function The traceback log server receives, analyzes and stores the address/ port address mapping information sent by NAT devices. The logic illustration of the log server is shown in Figure 1. +----------+ A +----------+ B +----------------+ |NAT Device|--- |Log Server|---|Traceback System| +----------+ +----------+ +----------------+ Figure 1: Location Of Log Server In The Network The log server acquires dynamic address/port mapping information from Chen, et al. Expires January 4, 2013 [Page 3] Internet-Draft Syslog Requirements for NAT Log July 2012 the NAT device via interface A, and provides the mapping information to the traceback system (or AAA) via interface B. 2. Terminology 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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. :Logging information: In this document, this specifically means dynamic address/port mapping logging information. 3. The Requirements of Log Server Function This section defines the basic requirements for the log server. o It MUST support The Syslog Protocol [RFC5424]. o It MUST support Transport Layer Security (TLS) Transport Mapping forSyslog [RFC5425]. o It MUST support Transmission of Syslog Messages over UDP [RFC5426]. The log server must support sending the syslog log using standard UDP port 514, and support sending syslog log using any one self-configured port of the user. o It is suggested to support Reliable Delivery for Syslog [RFC3195]. o It MUST support the Radius message format defined in [RFC2865] or [RFC2866]. o It MUST support acquiring user's dynamic address/port mapping information from NAT device. o It MUST support the functions of log query, storage, filter, duplication removal, collection and statistic analysis. o The storage information of the log server MUST include the following information, but not limited to: * Application name * Hostname Chen, et al. Expires January 4, 2013 [Page 4] Internet-Draft Syslog Requirements for NAT Log July 2012 * Start time * Original source IP * Translated source IP * Translated source start port * Translated source stop port 4. The Log Server Interface Requirements The log server MUST select one interface between syslog and radius to communicate with NAT device. It MUST provide the query interface to the traceback system. 4.1. Syslog Interface The syslog message includes two parts: the HEADER and the MSG. The packet records the device operation using ASCII text, and the length of the packet should not exceed 1024 bytes. The minimum length of the syslog message is not limited in this document. 4.1.1. Definition of HEADER Part The HEADER part should include PRI,VERSION,TIMESTAMP,HOSTNAME,APP- NAME,PROCID and MSGID. The PRI field indicates the log type. The VERSION field denotes the version number of traceback log. The HOSTNAME field identifies the device that originally sent the syslog message. The TIMESTAMP field contains the timestamp of syslog generation. The NAT device that generates the timestamp MUST use the NTP protocol, to synchronize with other devices in the network. The APP-NAME field identifies the device name that originated the log message. The PROCID field is used to provide the log group which the log belongs to. One log group indicates a group of operations interrelated with each other, e.g., creating a translation table for one session and removing this table. The MSGID field identifies the type of the log messgae. The PRI,TIMESTAMP,HOSTNAME and MSGID are mandatory fields, and the APP-NAME, PROCID are optional fields. 4.1.1.1. PRI The PRI field is composed of Facility and Severity values. The algorithm of PRI is defined as: PRI = Facility*8+Severity. The definition of syslog function code (Facility) is shown in Figure 2. Chen, et al. Expires January 4, 2013 [Page 5] Internet-Draft Syslog Requirements for NAT Log July 2012 Code Value Facility 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslog 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Figure 2: Definition of Facility In this document, the Facility value is denoted to be 16. The definition of syslog severity code (Severity) is shown in Figure 3. Code Value Severity 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Figure 3: Definition of Severity In this document, the Severity value is denoted to be 6. Chen, et al. Expires January 4, 2013 [Page 6] Internet-Draft Syslog Requirements for NAT Log July 2012 4.1.1.2. VERSION The VERSION filed is set to 1. 4.1.1.3. TIMESTAMP The format of TIMESTAMP is as below: < year> < mon> < day> < hh:mm:ss> year indicates the year the operation happens, which must be four digits, e.g., "2012". mon indicates month, and it could be one of the following values:Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov and Dec. day denotes the date, from 1 to 31. Hh, mm and ss separately denote the hours, minutes and seconds. 4.1.1.4. HOSTNAME The HOSTNAME field identifies the IPv4 address of the originating device, which is in the format of the dotted decimal notation, e.g., 10.1.1.1. 4.1.1.5. APP-NAME The APP-NAME field identifies the name of the device that originated the syslog message. It could be configured to the device by the manager, denoting the type of device, deployment site and model. 4.1.1.6. PROCID The PROCID field is used to provide the number for a log group (the length of the number is suggested to be 16 bytes), which includes digits and characters. It identifies the interrelated logs in one device. The PROCID is allocated sequencely to the log group and could be used repeatedly for the next allocation. 4.1.1.7. MSGID The MSGID field identifies the type of the message. The format is defined as: < device type>: < message type>. In the NAT444 environment, the device type is NAT444. In the DS-Lite environment, the device type is DSLITE. The message type in MSGID includes: o UserbasedA:this message is for user based log allocation. o SessionbasedA:this message is for session based log allocation. Chen, et al. Expires January 4, 2013 [Page 7] Internet-Draft Syslog Requirements for NAT Log July 2012 o UserbasedW:this message is for user based log withdrawal. o SessionbasedW:this message is for session based log withdrawal. For example, the MSGID of user based log allocation for a DS-Lite device is:DSLITE:userbasedA. 4.1.2. Definition of MSG Part The MSG part uses the ASCII characters. It MUST include the following contents: o L4 application identification:1 indicates ICMP; 6 indicates TCP and 17 indicates UDP. o Original Source IP:Source IPv4 address before translation. o Original Source IPv6:Source IPv6 address before translation. o Translated Source IP:Source IPv4 address after translation. o Original Port:Source port before translation. o Translated First Source Port:The first source port after translation, or source port after translation in session based translation. o Translated Last Source Port:The last source port after translation. The format of MSG part is:[ < Original Source IP > < Original Source IPv6> < Translated Source IP > < Original Port > < Translated First Source Port > < Translated Last Source Port >]. for the parameters not existed in certain type of devices, the "-" is used. Two examples: 1. Session based UDP port mapping allocation in NAT444 case:[17 10.0.0.1 - 192.168.0.1 - 10000 11000]. 2. Session based TCP port mapping allocation in DS-Lite case:[6 - 2001::1 192.168.1.1 80 80 -]. 4.1.3. Examples The following is an example of the syslog log message for user based UDP allocation in NAT444 case: < 134> 1 2012 Jun 7 12:34:08 10.1.1.1 nat444-jiangsu - NAT444:userbasedA [17 10.0.0.1 - 192.168.0.1 - 10000 Chen, et al. Expires January 4, 2013 [Page 8] Internet-Draft Syslog Requirements for NAT Log July 2012 11000]. 4.2. The Radius Interface Requirements The radius interface should use the Raidus message format defined in [RFC2865] or [RFC2866]. for the first traceback solution introduced above, there is no change to the radius interface. The syslog message format is shown in section 4.1. for the solution 2, the traceback information is carried in the radius Accounting-Request packet. The attributes are extended as below: | Sub-Attr|Sub-Attr|Maximum| Type|Description | Notes | | Name |Number |Length | | | | +---------+--------+-------+------+------------+----------------------+ | Vendor Extension:Vendor-ID is owned by each vendor | +---------+--------+-------+------+------------+----------------------+ |USER-ADDR| 120 | 4 |Integ |Indicates |0-Public IPv4 user; | |ESS-TYPE | | |er |users access|1-Private IPv4 user; | | | | | |address type|2-Public DS user; | | | | | | |3-Private DS user; | | | | | | |4-DS-Lite user; | | | | | | |5-Pure IPv6 user | +---------+--------+-------+------+------------+----------------------+ |USER-ADDR| 121 | 253 |String|Stores |This field contains | |ESS-LOG | | | |various log |mapping time, public | | | | | |information |address,original port,| | | | | |of NAT |destination port, | | | | | |translation |user address, each | | | | | | |separated by ":". | | | | | | |Example: mapping time | | | | | | |(YY/MM/DD/HH/MM/SS); | | | | | | |public address (IPv4);| | | | | | |user address (IPv4 or | | | | | | |IPv6) | +---------+--------+-------+------+------------+----------------------+ Figure 4: Attributes Extension For the radius server, USER-ADDRESS-TYPE attribute should be carried in the Accounting-Response message. For the BRAS side: Vendor-ID is owned by each vendor. The sub-attr name, sub-attr number and type could be defined by the vendor itself. In the solution 2, the private attributes reported should be the translated address and ports(source and destination). In the traceback solution 3, NAT device reports the dynamic user Chen, et al. Expires January 4, 2013 [Page 9] Internet-Draft Syslog Requirements for NAT Log July 2012 address/port mapping information to the log server using Radius message. For the radius server, USER-ADDRESS-TYPE attribute should be carried in the Accounting-Response message. For the BRAS side: Vendor-ID is owned by each vendor. The sub-attr name, sub-attr number and type could be defined by the vendor itself. BRAS reports the user traceback information to AAA server, in a delayed fixed time after sending the Accounting-Request message. Or BARS sends the information to other ports of the AAA server for which to collect the traceback information. In the solution 3, the private attributes reported should be the user account, mapping time, private address before translation, translated public address and ports(source and destination). 5. The Performance Requirements of The Log Server There are some requirements for the log server: o The packet processing capability of a single log server to receive syslog packet should not be less than 1,000 packets per second (CPU occupation rate should not exceed 50%). o The response time of a single log server to process syslog packet should be less than or equal to 10 ms. o The packet processing capability of a single log server to process log packet using Radius message should not be less than 1,000 packets per second (CPU occupation rate should not exceed 50%) o The response time of a single log server to process the log packet using Radius should be less than or equal to 10 ms. o The log should be stored in the storage system of the log server for 6 months. 6. The Reliability Requirements of The Log Server The requirements of reliability is listed as below: o The system should meet or exceed 99.999% usability. o The continuous work time without failure should be more than 100 thousand hours. Chen, et al. Expires January 4, 2013 [Page 10] Internet-Draft Syslog Requirements for NAT Log July 2012 o The failure recovery time should be less than 30 minutes. o High reliability and stability. Main processor, main cache, power and management interface should have hot standby capability. o The server should have 1:1 backup. o The blade system should support hot plug and pull. 7. IANA Considerations No request to IANA. 8. Security Considerations None. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009. [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009. Chen, et al. Expires January 4, 2013 [Page 11] Internet-Draft Syslog Requirements for NAT Log July 2012 Authors' Addresses Zhonghua Chen China Telecom P.R. China Phone: Email: 18918588897@189.cn Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathy.zhou@huawei.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com Chen, et al. Expires January 4, 2013 [Page 12]