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]
