Routing Area Working Group Miao Fuyou Internet Draft Huawei Technologies Expires: December 2005 July 5, 2005 TTL Partition Security Mechanism draft-miao-ttl-partition-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may only be posted in an Internet-Draft. 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 January 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Miao Expires December 5, 2005 [Page 1] Internet-Draft TTL Partition Security Mechanism June 2005 Abstract This draft proposes a TTL-number space "partition" mechanism to shield the access control/management plane of a service provider's (SP) core network from customer traffic. Provider edge routers limit the TTL to a preset maximum value on_USER_data packet that enters core network, and the core network router drops packet with a TTL as small as or smaller than preset value when the packet destination address is the router itself. Since attack packets from a customer site cannot reach the control plane or application of routers in the SP core network, the control plane of the core network is secured against the class of attacks originating outside the core network. 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................................................3 2. Assumptions.................................................3 3. TPSM Procedure..............................................4 3.1. Selecting Parameter Values..............................5 3.2. SP internetworking......................................5 4. Other Considerations.........................................6 4.1. Management Data.........................................6 4.2. ICMP Consideration......................................6 4.2.1. Time Exceeded Message IPv4 and IPv6 ..............6 4.2.2. Internet Header + 64 bits of Original Data Datagram.6 4.2.3. Request/Response ICMP messages.....................7 4.2.4. Ping..............................................7 4.2.5. TraceRoute.........................................7 4.3. TTL of MPLS Labeled Packet..............................8 4.4. Tunneling..............................................8 4.5. NAT/NAPT...............................................8 5. Security Considerations......................................8 6. Acknowledgments.............................................8 7. References..................................................9 7.1. Normative References....................................9 7.2. Informative References..................................9 Author's Addresses............................................10 Intellectual Property Statement................................10 Disclaimer of Validity........................................10 Miao Expires January 5, 2006 [Page 2] Internet-Draft TTL Partition Security Mechanism June 2005 Copyright Statement...........................................11 Acknowledgment................................................11 1. Introduction The TTL Partition Security Mechanism(TPSM) is designed to protect core network against attacks from customer networks. The mechanism introduces TTL-number space modification and packet filter to achieve the goal. The mechanism complements the generalized TTL security mechanism in design philosophy [GTSM], which allows a service provider to limit the number of hops between routing protocol peers. The network's TTL- number space is divided into customer (or other SP) network and core network, and this partitioning is enforced in the SP network to keep the core secure. GTSM says which packet addressed to it is trustable and should be processed, and TPSM says which packet addressed to it is not so trustable and should be dropped. Typically SP connect customer network to SP network using one or more provider edge(PE) router with links to customer edge(CE) devices. There are also other routers (P) that in core network don't connect directly to any CE. A P connects other Ps or PEs. Sometimes there is access network between core and customer. Because it is usually a level 2 network, it will not affect IP layer processing, then TPSM. TPSM shall not be treated as a substituting mechanism for authentication, and it can not defense attack from core network, such as spoofing or replay. The Hop Limit field in the IPv6 header has the same semantics as TTL in IPv4 from the perspective of TPSM. In the reminder of this document the term "TTL" is used to refer to both TTL and Hop Limit. 2. Assumptions The TTL partition security mechanism is based on the following assumptions: o The topology of core network is not so complex or its scale is not so large that need a packet to traverse as many as 128 hops to reach PE that connects destination customer network. Miao Expires January 5, 2006 [Page 3] Internet-Draft TTL Partition Security Mechanism June 2005 o IGP routing or other control information from outside the core network is not necessary for the core network to function properly. o Normal_USER_need not ping nodes in core network or trace into core network by TraceRoute. o Although TPSM is optional, when implemented in an SP network it SHALL be configured in all PEs and Ps in the core network.. 3. TPSM Procedure The core network is comprised of PE and P routers, major security threats are from CE that PE connects. If P/PE in core network can identify a packet is from CE or not, it can process the packet in different manners. PE connects CE directly at the IP layer, although the connection may traverse a layer 2 access network), so the PE can identify whether the packet is from CE. If it's from CE, the packet is marked to make it distinguishable by P and PE router. One P or other PE routers finds the packet destined to itself and marked, it promptly drop the packet. There is TTL field in IPv4 header and similar field as Hop Limit in IPv6. They are initialized a value up to 255 when a IP packet is constructed, and decrement 1 by each layer 3 forwarding node. This mechanism is devised to prevent permanent forwarding loops in IP networks. For each PE of a core network, a value TTL_USER_MAX is specified as TTL upper limit for any packet coming from CE. If the incoming packet from CE to PE has a TTL bigger than TTL_USER_MAX the TTL field will be updated with TTL_USER_MAX. In the same time for all P and PE router, 255 - TrustRadius[GTSM] is specified as lower limit for any packet destined to P or PE from routers other than CE (i.e. P or PE). If the incoming packet from P/PE to P/PE had a TTL smaller than 255 - TrustRadius, and the packet is addressed to the P/PE itself, the packet is silently dropped or delivered to a security module for strict scrutiny. If the packet is not addressed to the PE/P router itself, the packet will be forwarded normally. Miao Expires January 5, 2006 [Page 4] Internet-Draft TTL Partition Security Mechanism June 2005 3.1. Selecting Parameter Values The TTL_USER_MAX must be smaller than 255 - TrustRadius, or else the P/PE can not differentiate a packet originating from customer site or core network. TTL_USER_MAX and TrustRadius must be carefully chosen. The complexity and scale of core network and customer network will affect the choice of the value. o TTL_USER_MAX should be set to "a sufficiently large value", but in no case should be equal to, or greater than, 255 - - TrustRadius o 255 - TrustRadius should be large enough to allow routing peers to reach each other, or else routing packet will be silently dropped by P/PE. It is expected network to have TTL_USER_MAX set much higher than most user application set initial TTL. It is observed that Microsoft Windows TCP/IP stack currently set initial TTL to 128, Linux set the default value to 64 and most Unix TCP/IP stacks set it to 64 or 60. In the same time most Ping implementation sets TTL to 255. If the TTL_USER_MAX is set "a sufficiently large value", TTL of most user packets will not be modified to TTL_USER_MAX. So, "plentiful" TTL expiration is not expected to happen. By setting the parameters, the TTL-number space of the core network is partitioned into two parts. One part is user data with TTL smaller than (or equal to) TTL_USER_MAX. Another part is SP data (control plane, management plane or other SP specific application) with TTL larger than (or equal to) 255 - TrustRadius. There is no TTL overlap between the two parts. 3.2. SP internetworking Two core networks owned by different SPs are connected together by respective PEs. Each PE in an SP core network implementing TPSM can treat any peering PE in other SP network as CE. An alterative method is to treat the internetworking PE as P routers and both SPs implement TPSM with same parameters (TTL_USER_MAX and TrustRadius). In this case packet originating from on SP network can be processed just like it is from same core network. This trust relationship makes the SP network vulnerable to attacks from another SP network, and should only be implemented by SPs with high-degree trust. Miao Expires January 5, 2006 [Page 5] Internet-Draft TTL Partition Security Mechanism June 2005 4. Other Considerations 4.1. Management Data Management traffic to core network shall not be treated as traffic from customer site. The PE forwarding management packets to core network SHOULD NOT update TTL as description in section 3, but decrements TTL as usual. A specific PE port MAY be allocated only as egress point to core network for management traffic. Once such port is allocated, customer traffic MUST NOT enters core network by the same port. Typically management traffic is data from SSH, SNMP or other application/service. 4.2. ICMP Consideration TPSM impacts two aspects of ICMP: o The ICMP message type relevant to TTL of Packet o The ICMP packet from customer site addressed to a core network router is dropped 4.2.1. Time Exceeded Message IPv4 and IPv6 A packet modified by a PE router may be dropped with TTL = 0, although it may not have traversed number of hops the sender expected. In this case, the Time Exceeded ICMP message is sent to the source, as in normal operation. This consequence suggests TTL_USER_MAX shall be selected as great as possible when 255-TrustRadius does not impact forwarding of routing information in core network. 4.2.2. Internet Header + 64 bits of Original Data Datagram Some ICMP messages have a field "Internet Header + 64 bits of Original Data Datagram". The TTL value in this field is not accurate in a TPSM application and care should be taken when using it for analysis. In IPv6 the corresponding field is "As much of invoking packet as possible without the ICMPv6 packet exceeding the minimum IPv6 MTU"[ICMPv6]. Miao Expires January 5, 2006 [Page 6] Internet-Draft TTL Partition Security Mechanism June 2005 4.2.3. Request/Response ICMP messages The following ICMP Request messages from customer network addressed to a router in core network will be dropped by destination. Such messages include Echo, TimeStamp and Information Request for IPv4 and Echo for Ipv6 messages. The Response messages (Echo Replay, TimeStamp Reply and Information Reply) will not be generated by router. Other ICMP messages (Destination Unreachable, Time Exceeded and Parameter Problem for both IPv4 and IPv6, Redirect and Source Quench for IPv4, and Packet Too Big for IPv6) can be generated and sent to corresponding host as in normal operation. 4.2.4. Ping With TPSM it is impossible to get an ICMP Echo response by pinging a router in an SP core network from a customer site. When a host in one customer network pings a host in another customer network connected by a core network with TPSM the host can get a response from pinged host, but the TTL may not reflect the exact number of hops the packet traversed. 4.2.5. TraceRoute When a host in customer network tries to get router list on the path to a router in core network by TraceRoute, it will not get Echo Reply message from destination routers, but it can get the router list on the path both in its customer network and core network by Time Exceeded message from routers on the path. When a host in customer network tries to get router list on the path to a host in another customer network by TraceRoute, it will be able to trace into the core network. Router in core network drops the packet with TTL=0 and sends a Time Exceeded (both in IPv4 and IPv6) ICMP message back to the source host. This will allow customers to trace into the core network and disclose topology and other information to customer, which could be utilized to launch attacks by malicious user. One countermeasure for such reconnaissance is to silently drop the message with TTL=0 without any response. The drawback is that TraceRoute can't work properly even if an administrator traces a path from one router to another one in same core network. Another solution to overcome this shortcoming is to filter the Time Exceeded Message when it pass PE router from core network. If TTL of the Time Exceeded message is bigger than TTL_USER_MAX, the message is silently dropped. Miao Expires January 5, 2006 [Page 7] Internet-Draft TTL Partition Security Mechanism June 2005 4.3. TTL of MPLS Labeled Packet In [RFC3031] there are two kinds of procedures for TTL of labeled packet. When MPLS label value are carried in MPLS specific "shim" header TTL is copied from IP header to TTL shim header and decremented at each LSR-Hop. The TTL in shim header should be copied back to IP header when the packet leaves the LSP. If MPLS label value is encoded in data link layer, the LSP is assumed to be one hop. TTL must be consistently processed for all packets entering core network, even if the packet is MPLS labeled. For the first case PE SHOULD process TTL of MPLS shim header in the same work as IP header(section 3). For the second case PE SHOULD check and update TTL of IP header in the way specified in section 3. It SHOULD not simply switch the frame directly with TTL in IP header unchecked and intact. 4.4. Tunneling TBD 4.5. NAT/NAPT TBD 5. Security Considerations This draft provides additional assurance to network operators using GTSM, since PE routers are actively filtering customer packets that would fall within the TrustRadius for PE devices. 6. Acknowledgments To be added. Miao Expires January 5, 2006 [Page 8] Internet-Draft TTL Partition Security Mechanism June 2005 7. References 7.1. Normative References [RFC791] J. Postel, "Internet Protocol Specification", STD 5, RFC 791, September 1981. [RFC792] J. Postel, "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2365] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, July 1998. [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS LabelStack Encoding", RFC 3032, January 2001. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [ICMPv6] A. Conta, S. Deering and M. Gupta, "Internet Control Message Protocol(ICMPv6) for the Internet Protocol Version 6(IPv6) Specification", draft-ietf-ipngwg-icmp-v3-06.txt, Work in progress. 7.2. Informative References [GTSM] Vijay Gill, John Heasley and David Meyer, "The Generalized TTL Security Mechanism (GTSM)", draft-ietf-rtgwg- rfc3682bis-05.txt, Work in progress. Miao Expires January 5, 2006 [Page 9] Internet-Draft TTL Partition Security Mechanism June 2005 Author's Addresses Miao Fuyou Huawei Technologies Co., Ltd. No.3 Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing-100085 Phone: 86-10-8288 2502 Email: miaofy@huawei.com 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 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. Miao Expires January 5, 2006 [Page 10] Internet-Draft TTL Partition Security Mechanism June 2005 Copyright Statement Copyright (C) The Internet Society (2005). 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. Miao Expires January 5, 2006 [Page 11]