Operational Security Capabilities J. Kristoff
for IP Network Team Cymru
Infrastructure M. O'Reirdan
Internet-Draft Comcast
Intended status: BCP F. Gont
Expires: September 2, 2010 UTN/FRH
March 1, 2010
Port Filtering Considerations
draft-kristoff-opsec-port-filtering-00.txt
Abstract
This document provides advice and technical guidance for ISP port
filtering.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 September 2, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Kristoff, et al. Expires September 2, 2010 [Page 1]
Internet-Draft Port Filtering Considerations March 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Kristoff, et al. Expires September 2, 2010 [Page 2]
Internet-Draft Port Filtering Considerations March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Perimeter-based Security . . . . . . . . . . . . . . . . . . . 4
3. Filter Placement . . . . . . . . . . . . . . . . . . . . . . . 5
4. Ingress Edge Host Shielding . . . . . . . . . . . . . . . . . 6
5. Ingress Shielding Rate Limits . . . . . . . . . . . . . . . . 7
6. Performance Considerations . . . . . . . . . . . . . . . . . . 8
7. Support Considerations . . . . . . . . . . . . . . . . . . . . 9
8. Filter Rule Design . . . . . . . . . . . . . . . . . . . . . . 10
9. Future Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Opt In / Opt Out . . . . . . . . . . . . . . . . . . . . . . . 12
11. Email filtering . . . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Shielding Filter Example, Cisco IOS . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Kristoff, et al. Expires September 2, 2010 [Page 3]
Internet-Draft Port Filtering Considerations March 2010
1. Introduction
Many networks have implemented a variety of mechanisms to prevent or
limit certain types of network traffic from traversing their networks
or reaching certain classes of systems. This activity, which we
generically refer to simply as "filtering" can take many forms and be
instituted for a number of purposes. "Port filtering" is a specific
class of stateless Internet packet filtering based on the port number
fields found the protocols that provide an interface between the
Internet Protocol (IP) below and application layers above. Common
protocols that implement these port identifiers include the
transmission control protocol (TCP), user datagram protocol (UDP),
stream control transmission protocol (SCTP) and the datagram
congestion control protocol (DCCP). We aim to offer high-level
guidance to networks who are currently or are considering utilizing
port filters.
Filtering policies are often a contentious issue and can spark
lengthy debates. We avoid rehashing those discussions. We do
highlight architectural and technical issues where particular
filtering policies have shown noteworthy side effects from practical
experience. Others have published extensively on architectural
principles that are worthy of the reader's attention [TODO: ref to
Salzer, Clark and Reed paper, IETF RFC 1958, IETF RFC 2775, IETF RFC
3439, what credible anti-transparency or pro-filtering references are
there?].
The rest of this document is organized as follows. The first section
outlines problems that can arise from port filtering, and where
appropriate discusses how to mitigate them. The remainder of the
document outlines from a high-level, common port filtering scenarios
are being widely implemented.
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 [RFC2119].
Kristoff, et al. Expires September 2, 2010 [Page 4]
Internet-Draft Port Filtering Considerations March 2010
2. Perimeter-based Security
The point in the network where port filtering is applied results in a
defined perimeter, or delineation of a good "inside" and bad
"outside" [ref RFC 3631 3.11]. Systems common to a particular area
or "side" share an implicit trust relationship. As the number of
systems in an area grows, the number of implicit trust relationships
in that area may grow expotentially. With port filtering, in
practice this only occurs if all systems are sharing a common set of
applications and ports. Likewise, as the number of systems in an
area or side decreases, implicit trust relationships in shared
applications and ports decline. For large networks, filters may need
to be applied throughout the infrastructure to be effective, yet may
become an increasingly difficult distributed management challenge.
Kristoff, et al. Expires September 2, 2010 [Page 5]
Internet-Draft Port Filtering Considerations March 2010
3. Filter Placement
Mechanisms exist in current Internet systems that perform filtering
at almost any point in communications path. In ISP networks, port
filters are most often set in router configurations. These routers
also perform the route selection and packet formwarding duties of
transit traffic. In some cases, ISPs use specialized devices
generically referred to as firewalls that inspect or intercept
packets as they traverse the path. Firewalls often reside next to or
in some cases may be integrated into routing devices. These devices
are dedicated to filtering and related duties, but do not generally
perform the routing and forwarding functions of the traditional
routering system.
Kristoff, et al. Expires September 2, 2010 [Page 6]
Internet-Draft Port Filtering Considerations March 2010
4. Ingress Edge Host Shielding
Edge networks consisting of only end hosts and are used primarily for
client-based applications have been successfully put behind
&shielding& filters and rate limits. If it is known that these hosts
will require limited stable server processes, the goal is to limit
their exposure to server processes and minimize their ability to
generate abusive traffic. A balance between protection, support and
transparency is a delicate balance. Care must be taken to avoid
preventing access to current or future client-based services through
the use of filters.
Kristoff, et al. Expires September 2, 2010 [Page 7]
Internet-Draft Port Filtering Considerations March 2010
5. Ingress Shielding Rate Limits
Rate limits artificially constrain the amount, optionally by type, of
traffic that may be sourced by an edge host. It is common for
typical client-based hosts on the Internet to use TCP for the bulk of
the source traffic, particularly for high-speed transfers and where a
congestion-avoidance friendly protocol is desired. Therefore, rate
limits for other protocol types to an acceptable rate that leave the
bulk of the available capacity to the TCP or TCP-like packets have
been used.
Kristoff, et al. Expires September 2, 2010 [Page 8]
Internet-Draft Port Filtering Considerations March 2010
6. Performance Considerations
Kristoff, et al. Expires September 2, 2010 [Page 9]
Internet-Draft Port Filtering Considerations March 2010
7. Support Considerations
TODO: troubleshooting and diagnosis issues, documentation
Kristoff, et al. Expires September 2, 2010 [Page 10]
Internet-Draft Port Filtering Considerations March 2010
8. Filter Rule Design
TODO: order and anomalies with rules
Kristoff, et al. Expires September 2, 2010 [Page 11]
Internet-Draft Port Filtering Considerations March 2010
9. Future Considerations
TODO: future app support, flexiblity, new protocols
Kristoff, et al. Expires September 2, 2010 [Page 12]
Internet-Draft Port Filtering Considerations March 2010
10. Opt In / Opt Out
Kristoff, et al. Expires September 2, 2010 [Page 13]
Internet-Draft Port Filtering Considerations March 2010
11. Email filtering
Kristoff, et al. Expires September 2, 2010 [Page 14]
Internet-Draft Port Filtering Considerations March 2010
12. Security Considerations
None.
Kristoff, et al. Expires September 2, 2010 [Page 15]
Internet-Draft Port Filtering Considerations March 2010
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kristoff, et al. Expires September 2, 2010 [Page 16]
Internet-Draft Port Filtering Considerations March 2010
Appendix A. Shielding Filter Example, Cisco IOS
These examples assume BCP 38/84 are in effect, but are not shown for
brevity.
interface FastEthernet0/0
ip address 192.0.2.0 255.255.255
ip access-group shield-filter-in in
ip access-group shield-filter-out out
! 2 Mb/s source ICMP limit for entire edge net
rate-limit input access-group 2000 2000000 375000 750000
conform-action transmit exceed-action drop
! 10 Mb/s source UDP (non-multicast) limit for entire edge net
rate limit input access-group 2001 10000000 1875000 3750000
conform-action transmit exceed-action drop
! 10 Mb/s source IP/UDP multicast limit for entire edge net
rate limit source access-group 2002 1000000 1875000 3750000
conform-action transmit exceed-action drop
! 2 Mb/s source IGMP limit for entire edge net
rate limit input access-group 2003 2000000 375000 750000
conform-action transmit exceed-action drop
! 10 Mb/s source IPsec limit for entire edge net
rate-limit input access-group 2004 10000000 1875000 3750000
conform-action transmit exceed-action drop
! 10 Mb/s source GRE limit for entire edge net
rate-limit input access-group 2005 10000000 1875000 3750000
conform-action transmit exceed-action drop
! 10 Mb/s source limit for all other non-TCP-friendly protocols
rate-limit input access-group 2500 10000000 1875000 3750000
conform-action transmit exceed-action drop
access-list 2000 remark ICMP - for edge ingress rate limit
access-list 2000 permit icmp any any
access-list 2000 deny ip any any
access-list 2001 remark UDP (non-multicast) - for edge ingress
rate limit
access-list 2001 deny udp any 224.0.0.0 15.255.255.255
access-list 2001 permit udp any any
access-list 2001 deny ip any any
access-list 2002 remark IP/UDP multicast - for edge ingress
rate limit
access-list 2002 permit udp any 224.0.0.0 15.255.255.255
access-list 2002 deny ip any any
Kristoff, et al. Expires September 2, 2010 [Page 17]
Internet-Draft Port Filtering Considerations March 2010
access-list 2003 remark IGMP - for edge ingress rate limit
access-list 2003 permit igmp any 224.0.0.0 15.255.255.255
access-list 2003 deny ip any any
access-list 2004 remark IPsec - for edge ingress rate limit
access-list 2004 permit ahp any any
access-list 2004 permit esp any any
access-list 2004 deny ip any any
access-list 2005 remark GRE - for edge ingress rate limit
access-list 2005 permit gre any any
access-list 2005 deny ip any any
access-list 2500 remark default - for edge ingress rate limit
access-list 2500 deny icmp any any
access-list 2500 deny igmp any any
access-list 2500 deny udp any any
access-list 2500 deny tcp any any
access-list 2500 deny ahp any any
access-list 2500 deny esp any any
access-list 2500 deny gre any any
access-list 2500 permit ip any any
ip access-list extended shield-filter-in
remark [subnet description] (full shielding) - inbound
!
! allow high numbered TCP source ports
permit tcp any gt 1023 any
!
! allow high numbered UDP source ports
permit udp any gt 1023 any
!
! allow GRE (required for PPTP)
permit gre any any
!
! allow IPSec (next 3 lines)
permit esp any any
permit udp any eq isakmp any
permit ahp any any
!
! allow UDP limited broadcasts
permit udp any host 255.255.255.255
!
! allow UDP multicast
permit udp any 224.0.0.0 15.255.255.255
!
! allow DHCP clients
permit udp host 0.0.0.0 host 255.255.255.255 eq bootps
Kristoff, et al. Expires September 2, 2010 [Page 18]
Internet-Draft Port Filtering Considerations March 2010
!
! allow NTP (some clients use 123 for both src and dst port)
permit udp any eq ntp any eq ntp
!
! allow TCP source port 113 (IDENT)
permit tcp any eq ident any
!
! allow IGMP
permit igmp any 224.0.0.0 15.255.255.255
!
! allow ICMP echo messages (PING)
permit icmp any any echo
!
! allow ICMP echo response messages (PONG)
permit icmp any any echo-reply
!
! allow ICMP parameter problem messages
permit icmp any any parameter-problem
!
! allow ICMP TTL exceeded messages
permit icmp any any time-exceeded
!
! allow ICMP unreachable messages
permit icmp any any unreachable
!
! deny everything else by default and log it
deny ip any any log-input
ip access-list shield-filter-out
remark [subnet description] (full shielding) - outbound
!
! allow high numbered TCP destination ports
permit tcp any any gt 1023
!
! allow high numbered UDP destination ports
permit udp any any gt 1023
!
! allow GRE (required for PPTP)
permit gre any any
!
! allow IPSec (next 3 lines)
permit esp any any
permit udp any any eq isakmp
permit ahp any any
!
! allow UDP multicast
permit udp any 224.0.0.0 15.255.255.255
!
Kristoff, et al. Expires September 2, 2010 [Page 19]
Internet-Draft Port Filtering Considerations March 2010
! allow NTP (some clients use 123 for both src and dst port)
permit udp any eq ntp any eq ntp
!
! allow TCP destination port 113 (IDENT)
permit tcp any any eq ident
!
! allow IGMP
permit igmp any 224.0.0.0 15.255.255.255
!
! allow ICMP echo messages
permit icmp any any echo
!
! allow ICMP echo response messages
permit icmp any any echo-reply
!
! allow ICMP parameter problem messages
permit icmp any any parameter-problem
!
! allow ICMP TTL exceed messages
permit icmp any any time-exceeded
!
! allow ICMP unreachable messages
permit icmp any any unreachable
!
! deny everything else by default and log it
deny ip any any log-input
Figure 1
Kristoff, et al. Expires September 2, 2010 [Page 20]
Internet-Draft Port Filtering Considerations March 2010
Authors' Addresses
John Kristoff
Team Cymru
16W361 S. Frontage Road
Suite 100
Burr Ridge, IL 60527
US
Phone: +1 630 230-5400
Email: jtk@cymru.com
URI: http://www.team-cymru.org
Michael O'Reirdan
Comcast
Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fernando@gont.com.ar
URI: http://www.gont.com.ar
Kristoff, et al. Expires September 2, 2010 [Page 21]