Internet DRAFT - draft-miao-ttl-partition

draft-miao-ttl-partition



Routing Area Working Group                                 Miao Fuyou 
Internet Draft                                     Huawei Technologies 
Expires: March 2006                                 September 24, 2005 
                                   
 
                                      
                     TTL Partition Security Mechanism 
                      draft-miao-ttl-partition-01.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 March 24, 2006. 

Copyright Notice 

      Copyright (C) The Internet Society (2005).  All Rights Reserved. 


 
                                                 
 
Miao                   Expires March 24, 2006                 [Page 1] 

Internet-Draft    TTL Partition Security Mechanism      September 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  ..............7 
         4.2.2. Internet Header + 64 bits of Original Data Datagram.7 
         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 March 24, 2006                 [Page 2] 

Internet-Draft    TTL Partition Security Mechanism      September 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 March 24, 2006                 [Page 3] 

Internet-Draft    TTL Partition Security Mechanism      September 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 March 24, 2006                 [Page 4] 

Internet-Draft    TTL Partition Security Mechanism      September 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. 

   Sometimes one SP has several sites connected by another SP that 
   provides backbone connectivity to served SPs by VPN. Subsequently the 
   served SP provides access service for home or enterprise customers. 
 
 
Miao                   Expires March 24, 2006                 [Page 5] 

Internet-Draft    TTL Partition Security Mechanism      September 2005 
    

   The backbone connectivity provider is called carrier's carrier. The 
   served SP can implement TPSM for its network independently without 
   extra complexity. The only thing care should be taken for is the 
   range of TTL segment. If the VPN is provisioned with MPLS tunnel the 
   TTL range should be allocated bigger than usual because TTL is also 
   decremented in the network of carrier's carrier[RFC3031].  

   using TPSM for PEs where you sell ''carrier's carrier'' services that 
   do not use MPLS tunnels is out of scope of this draft. 

4. Other Considerations 

    4.1. Management Data 

   Management traffic to core network shall not be treated as traffic 
   from customer site. A specific PE port MAY be allocated as ingress 
   point to core network exclusively for management traffic. Once such 
   port is allocated, customer traffic MUST NOT enters core network by 
   the same port. The management packets should have an initial TTL of 
   255, or else it may be dropped by destination in core network. The PE 
   forwarding management packets to core network SHOULD NOT update TTL 
   as description in section 3, but decrements TTL as usual.  

   Typically management traffic is data from SSH, SNMP or other 
   application/service. 

    4.2. DHCP and DNS servers 

   It is important for customers/users to access DHCP or DNS server of 
   the SP. If TPSM is deployed, the servers MUST NOT resides in the core 
   network unless they co-locate with a PE and they only serve the 
   customers/users the PE connects. Another choice is to reside them in 
   some specific site out of the core network. The specific site can be 
   a firewall-protected DMZ connected to core network by a PE.  

    4.3. 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 




 
 
Miao                   Expires March 24, 2006                 [Page 6] 

Internet-Draft    TTL Partition Security Mechanism      September 2005 
    

4.3.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.3.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]. 

4.3.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.3.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.3.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 
 
 
Miao                   Expires March 24, 2006                 [Page 7] 

Internet-Draft    TTL Partition Security Mechanism      September 2005 
    

   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.  

    4.4. 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. 

5. Security Considerations 

   TPSM provides additional security assurance to network operators 
   using GTSM, since TPSM provides a mechanism for core network to tell 
   whether a packet is from outside or inside of the core network. 

6. Acknowledgments 

   The author would like to appreciate Forest Lei, who contributed the 
   primary idea of TPSM. Spencer Dawkins, Joel Halpern and many others 
   provided valuable feedback and comments for the document.  
 
 
Miao                   Expires March 24, 2006                 [Page 8] 

Internet-Draft    TTL Partition Security Mechanism      September 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 March 24, 2006                 [Page 9] 

Internet-Draft    TTL Partition Security Mechanism      September 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 March 24, 2006                [Page 10] 

Internet-Draft    TTL Partition Security Mechanism      September 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 March 24, 2006                [Page 11]