Policy Framework (policy) Chi Yudong Internet Draft Feng Jian Expires: Jan 2005 Zhong Weidong Du Ke ZTE, Inc Jiang Lintao CATR of MII Editors July 2004 ICMP Extensions for Policy-based Routing draft-ke-policy-icmp-ext-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on Jan 5, 2005. Summary ping/traceroute and other network diagnostic tools are widely used in the IP networks to diagnose the network reachability, IP packet routing and routing failure location. However, the existing ping/traceroute tools are adaptable only to the pure networks where the routing is based on destination address. When an IP packet Chi Yudong, et al. [Page 1] Internet Draft ICMP Extensions for Policy-based Routing July 2004 passes a certain equipment based on ACL policy routing, the ping/traceroute packet routing MAY be different from the real traffic flow routing. This will lead to an erroneous diagnostic result. This document presents an ICMP extension solution. The ICMP echo messages carry the flow description information of the traffic flow to be diagnosed, during the delivery process, the router routes according to the flow description information. This ensures that the ping/traceroute diagnostic packet will route along the traffic flow. Conventions used in this document 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]. Table of Contents 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 2 2 IP ALERT OPTION . . . . . . . . . . . . . . . . . . . . . . 3 3 PDU ENCAPSULATION FORMAT . . . . . . . . . . . . . . . . . . 4 4 PROTOCOL PROCESSING (SPECIFICATION) . . . . . . . . . . . . 7 5 NAT Equipment Processing . . . . . . . . . . . . . . . . . . 8 6 CAR EQUIPMENT PROCESSING . . . . . . . . . . . . . . . . . 8 7 BACKWARD COMPATIBILITY CONSIDERATION . . . . . . . . . . . . 9 8 SECURITY CONSIDERATION . . . . . . . . . . . . . . . . . . . 9 9 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 9 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 11 References . . . . . . . . . . . . . . . . . . . . . . . . 10 12 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 10 13 Intellectual Property Statement . . . . . . . . . . . . . . 11 14 Disclaimer of Validity . . . . . . . . . . . . . . . . . . 11 15 Copyright Statement . . . . . . . . . . . . . . . . . . . . 11 1 Introduction A router and a host may transmit the control information through the Internet Control Message Protocol (ICMP) [RFC-792], and the network administrator can use such control information to diagnose routing problems. There are two frequently used diagnostic tools, one is ping, by which the source site (a router or a host) sends several ICMP echo packets to the destination site (a router or a host). If the source site receives an ICMP reply packet which is replied by the destination site as response to receiving every such Chi Yudong, et al. [Page 2] Internet Draft ICMP Extensions for Policy-based Routing July 2004 an ICMP echo packet, it can diagnose the reachability of the destination site and the transmission delay; The other is traceroute, by which the source site sends ICMP or UDP packets whose TTL value ascends from 1, the router in-between then sends back in turn the ICMP errored messages due to TTL timeout until they reach the destination site, which then sends back the ICMP reply or ICMP port unreachable messages and record in turn the source address of relevant ICMP messages. traceroute can display the IP packet delivery path. But the mechanism (algorithm) mentioned above can apply only to the networks with pure destination IP address forwarding. During the delivery process, when a packet passes the equipment based on ACL policy routing, it may match different ACL rules and take different routes because the protocol types in the IP head are different, the tos fields are different, and the transmission layer ports are different. The ping/traceroute result cannot reflect the true routing and arrival of traffic flows. This document states that the ICMP echo message carries the flow description information of traffic flows, such as protocol type, source IP address, destination IP address, ports of transmission layer and Type of Service, and that the routers in-between forward ICMP echo packet according to the traffic flow description information carried in the packet, instead of destination IP address in the IP head. then the control information and the traffic flow routing can be consistent, thus achieving the purpose of truly detecting routes and correctly diagnosing routing problems. This document proposes the following extensions of the ICMP: 1) ICMP echo packet SHOULD carry the IP Alert option [RFC-2113]; 2) ICMP echo packet CAN carry flow description information of a certain traffic flow. If an ICMP echo packet carries such information, then it MUST carry the IP Alert option. 3) For the ICMP echo packets carrying flow description information, the routers MUST route according to the flow description information. To avoid the potential DoS (Denial of Service) attack, it is RECOMMENDED to limit the flow of ICMP packets entering the control layer in implementing this extension protocol. 2 IP Alert Option The purpose of an ICMP echo packet carrying the IP Alert option is Chi Yudong, et al. [Page 3] Internet Draft ICMP Extensions for Policy-based Routing July 2004 to notify the routers in-between to conduct in-depth check and processing of the ICMP echo packets. This extension requires that, if the PDU of an ICMP echo message contains the flow description information, then the ICMP packet MUST NOT route according to the IP head information (e.g., destination address), instead it should route according to the flow description information in the PDU. 3 PDU Encapsulation Format ICMP [RFC-792] prescribes its PDU format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For echo messages, the PDU format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(8) | Code(0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension prescribes that, for echo messages, the PDU format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(8) | Code(0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Length | Reserved(must be 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flow description information (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pad(Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chi Yudong, et al. [Page 4] Internet Draft ICMP Extensions for Policy-based Routing July 2004 PDU Length: 2 octets, which are equivalent to the length of TLVs. Reserved: 2 octets, you must fill 0 when sending, but ignore when receiving. In the flow description information field, the data are coded in the TLV (Type-Length-Value) format. The TLV is defined below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Valueí¡í¡ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 octet (Oct) = 0x41: Traffic flow protocol type; = 0x42: Traffic flow ToS (Type of Service) requirements; = 0x43: Traffic flow source address (IPv4); = 0x44: Traffic flow source port; = 0x45: Traffic flow destination address (IPv4); = 0x46: Traffic flow destination port; = 0x47: Authentication; = 0x48: Extension label; Notes: All type values are provisional, subject to assignment by IANA. Length: 2 octets (Octes) Always equals the Value length. Value: Parameter value, variant. 3.1 TLV format for traffic flow protocol type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x41) | Length(1) | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol: 1 octet (Oct), the protocol type of the traffic flow which requires the diagnosis, and whose value range SHALL conform to the [RFC-1700] stipulations. 3.2 TLV format for traffic flow ToS (Type of Service) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x42) | Length(1) | tos | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chi Yudong, et al. [Page 5] Internet Draft ICMP Extensions for Policy-based Routing July 2004 tos: 1 octet (Oct), the ToS (Type of Service) of the traffic flow which requires the diagnosis, and whose value range SHALL conform to [RFC-1700] stipulations. 3.3 TLV format for traffic flow source address (IPv4) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x43) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source IP(v4) address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ source IP(v4) address: 4 octets (Octs), the source address of the traffic flow which requires the diagnosis. 3.4 TLV format for traffic flow source port 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x44) | Length(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ source port: 2 octets (Octs), the source port of the traffic flow which requires the diagnosis. 3.5 TLV format for traffic flow destination address (IPv4) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x45) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination IP(v4) address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ destination IP(v4) address: 4 octets (Octs), the destination address of the traffic flow which requires the diagnosis. Chi Yudong, et al. [Page 6] Internet Draft ICMP Extensions for Policy-based Routing July 2004 3.6 TLV format for traffic flow destination port 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x46) | Length(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ destination port: 2 octets (Octs), the destination port of the traffic flow which requires the diagnosis. 3.7 TLV format for authentication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x47) | Length(1-80) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication text í¡í¡ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication text: 1-80 octets (Octs), authentication password. 3.8 TLV format for the extension label 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x48) | Length(20) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identification +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ identification text: 20 octets (Octs), extension protocol PDU label, whose value is 20 0xFCs. An ICMP echo message can, when necessary, carry several pieces of octet pad information. 4 Protocol Processing (Specification) ICMP extensions require that the ICMP echo packet carry the IP Alert option, and that the routers in-between conduct in-depth check and processing of the ICMP echo packets. If the PDU of the ICMP echo message contains the flow description information TLV, then such ICMP message MUST NOT route according to the information (e.g., destination address) in the IP head, instead, it routes according to the flow description information in the PDU. Chi Yudong, et al. [Page 7] Internet Draft ICMP Extensions for Policy-based Routing July 2004 When receiving the ICMP echo message, the routers in-between will send back the ICMP error messages as per ICMP[RFC-792] in case of TTL timeout. If the PDU packet of the ICMP echo message contains the flow description TLV, then the router will resolute such flow description, match the local routing policy, and route according to the matched routing policy. All the flow description TLVs are OPTIONAL. An ICMP echo message can carry whole or part of the flow description information, and the router in-between will route based on the received flow description information. The ICMP echo messages may not carry the flow description information. In this case, they will be processed according to standard ICMP[RFC-792]. The error-coded ICMP echo PDU is also treated as one without carrying the flow description information. Although more flow description information of the traffic flow can be defined to adapt the protocol to more wide application cases, the ICMP extensions only involve several parameters, such as protocol type, port-point pair of the transmission layer, and Type of Service, that are frequently used to influence the routing. To avoid the potential DoS (Denial of Service) attack, it is RECOMMENDED to limit the ICMP packet flow entering the control layer in implementing the protocol extension. 5 NAT Equipment Processing When the private network traffic flow goes to the public network through the NAT equipment, the source address of the traffic flow and the source port of the transmission layer will go through a conversion, so when the NAT equipment receives the ICMP echo messages of this protocol extension from the private network, it will undergo a conversion accordingly if the flow description information contains the traffic flow source address (IPv4) TLV or the traffic flow source port TLV. 6 CAR Equipment Processing On the edge of the telecom operator networks supporting TOS (Type of Service), you will often see the equipment there for traffic classification, which, based on the traffic flow classification, modifies and fills the IP tos field of the user traffic flow. The equipment in the core network can route according to the modified IP tos value. In this case, when the traffic classification equipment receives the ICMP echo messages of this protocol extension, it will under conversion if the flow description information contains the traffic flow ToS (Type of Service) require Chi Yudong, et al. [Page 8] Internet Draft ICMP Extensions for Policy-based Routing July 2004 TLV; it will add proper traffic flow ToS (Type of Service) to require TLV if the flow description information does not contain the traffic flow ToS (Type of Service) require TLV. 7 Backward Compatibility Consideration The ICMP extensions only requires the support by the equipments influencing routing policy (e.g., NAT and CAR) and the equipments supporting policy routing, but the hosts/terminals do not need upgrading or extension. The equipment that does not support the ICMP extensions will process the PDU of the extensions as the standard ICMP[RFC-792] packets. If this equipment does not influence the flow classification parameters of traffic flows and does not execute the policy routing, it will not affect the routing problem diagnosis, otherwise the result will not be true. To forestall the mistaking of the PDU of not this ICMP extensions as the PDU of the ICMP extension, the ICMP extensions take two measures: 1) The PDU of the ICMP extension MAY contain an "extension label TLV", whose PDU with an incorrect parameter value must be processed as the standard ICMP[RFC-792] echo message; 2) The error-coded ICMP echo PDU must be processed as a standard ICMP[RFC-792] echo message. 8 Security Consideration To avoid the potential DoS (Denial of Service) attack, it is RECOMMENDED to limit the flow of ICMP protocol packets entering the control layer in implementing the protocol extension. The network edge router can be configured with the ICMP ping/traceroute password. If a router has the ICMP ping/traceroute password, it will check the received PDU of the ICMP extension. If the PDU does not carry "Authentication TLV" or the "Authentication TLV" value dose not match the password, the router MAY discard it. 9 IANA Considerations (To be filled in in a later revision.) 10 Acknowledgments The authors wish to thank all the people who have contributed to this document through numerous discussions. Chi Yudong, et al. [Page 9] Internet Draft ICMP Extensions for Policy-based Routing July 2004 11 References [RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792, ISI, September 1981. [RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC-2434], T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [PLYFRAME], Stevens, M., et. al., Policy Framework, Internet Draft, , September 1999. [SECPOL], Srisuresh, P., Sanchez, L.A., "Policy Framework for IP Security, , February 1999. 12 Authors' Addresses Authors' Addresses Jiang Lintao CATR of MII CHINA Email: jianglt@public.bta.net.cn Chi Yudong ZTE Inc. CHINA Email: chi.yudong@zte.com.cn Feng Jian ZTE Inc. CHINA Email: feng.jian@zte.com.cn Zhong Weidong ZTE Inc. CHINA Email: zhong.weidong@zte.com.cn Du Ke ZTE Inc. CHINA Email: du.ke@zte.com.cn Chi Yudong, et al. [Page 10] Internet Draft ICMP Extensions for Policy-based Routing July 2004 13 Intellectual Property Statement 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. 14 Disclaimer of Validity 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. 15 Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chi Yudong, et al. [Page 11]