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,
<draft-ietf-policy-framework-00.txt>, September 1999.
[SECPOL], Srisuresh, P., Sanchez, L.A., "Policy Framework for IP
Security, <draft-ietf-ipsec-policy-framework-00.txt>,
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]