Network Working Group A. Shahid Internet-Draft S. Ahmed Expires: July 25, 2011 Cisco Systems January 21, 2011 Ingress filtering by using Wildcard mask bits draft-shahid-protect-edge-devices-00 Abstract Security of the IP Network is always one of the primary concerns of the network design and normally used layered approach. It is recommended not to rely on a single layer of defense, but to configure multi-layer security measures. The primary purpose of this paper is to propose a simple and effective solution to enhance the security of EDGE devices which are connected to external users in a Service Provider network. Most Service Providers commonly use ingress filtering as one of the methods to filter traffic to secure edge devices of their infrastructure from external users. The proposed technique will use a special wildcard mask on the network addresses to limit the accessibility of the Service Provider EDGE devices from external users. This will greatly enhance the security of the Service Provider's edge devices from malicious attacks such as Denial of Service (DoS). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 25, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Shahid & Ahmed Expires July 25, 2011 [Page 1] Internet-Draft ingress filtering January 2011 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 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Securing Service Providers EDGE Devices . . . . . . . . . . . 7 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Appendix: Cisco Configuration Examples . . . . . . . . . . . . 13 8. Requirements notation . . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Shahid & Ahmed Expires July 25, 2011 [Page 2] Internet-Draft ingress filtering January 2011 1. Introduction Security of the IP Network is always one of the main objectives of the network design. For better security, it is always recommended to configure multi-layer security measures and not to rely on a single layer of defense. First layer of defense is network inaccessibility which can be achieved by two methods: 1. Do not advertise the internal infrastructure IP to External users 2. Apply ingress policies at the perimeter of the network to block any traffic destined for internal infrastructure devices In a Service Provider (SP) environment, there are two types of infrastructure devices in terms of layer 3 connectivity i.e. INTERNAL and EXTERNAL devices. All interfaces of the INTERNAL devices remain inside of the SP network and external users connect to the EXTERNAL or EDGE devices of the SP network. CE2 (External User 2) / / / SP EDGE device#1<-->SP INTERNAL device<--->SP EDGE device#2 \ \ \ CE1 (External User 1) If the Service Provider is using a separate block of address space for INTERNAL connectivity, then it is simple to block all packets at the perimeter of the network and prevent the packets from reaching the Service Providers INTERNAL infrastructure devices. There are some challenges to secure the EDGE devices if the EXTERNAL address space is accessible from external networks and external users. To secure EDGE devices, the proposed technique uses ingress filtering method which is very common within SP's to secure infrastructure devices. The basic requirement of the proposed technique is to use separate address space for INTERNAL and EDGE devices. Shahid & Ahmed Expires July 25, 2011 [Page 3] Internet-Draft ingress filtering January 2011 Generally, the EXTERNAL address space is totally blocked from external networks and users to secure EDGE devices with few exceptions of directly connected devices. But some Service Providers make the external addresses of edge devices reachable from external source due to multiple reasons. One of the methods used by SP is to block the entire EXTERNAL address space from external users with few exceptions with directly connected devices at layer 3 IP protocol, for example, routing information needs to be exchanged with the directly connected edge device. Second exception is to allow ICMP packets to check the reachability for operational considerations to determine the state of the router interface. Since the whole EXTERNAL address space is blocked at the perimeter of the network, separate LAN IP is provided to external user to establish communication with other users and networks. Furthermore, this results to an unnecessary allocation of routable IP addresses and contributing towards the depletion of the IPv4 allocation pool. In the second scenario, some Service Providers open the EXTERNAL address space for external networks and users, and allow communication on the point-to-point IP at the cost of increased visibility of EDGE devices. The drawback of using the above method will be to make the EDGE devices more prone to attacks. But at the same time this will eliminate the unnecessary use of extra LAN IP addresses if customer can use NAT over the WAN IP addresses. It is very important to save routable IP addresses without compromising the EDGE device security for DOS and different type of attacks. Shahid & Ahmed Expires July 25, 2011 [Page 4] Internet-Draft ingress filtering January 2011 2. Proposed Solution An effective solution to overcome the limitations and disadvantages of the above scenarios is to use wildcard mask bits. In case of subnet mask of /30 (255.255.255.252), first usable IP is always be an ODD number (1,5,9,13 and so on) and second useable IP will be EVEN. External users and networks uses the IP from the EXTERNAL block to connect with the Service Providers EDGE devices. But External users and networks can only reach and access other External users and networks but not the Service Providers EDGE devices, which is using the same EXTERNAL address space, with the minor exceptions of directly connected device. To be able to satisfy this requirement, the following set of policies should be in place for the IP planning perspective: 1. All internal infrastructure IP's for Service Provider network devices should be assigned from a dedicated IP block. 2. Connectivity for External users and networks to the service provider routers should be from a separate IP block. This block should not overlap with Service Provider's internal infrastructure network block. 3. Consistent policy of IP assignment should be in place, for example, first usable IP should always be on Service Providers network and second useable IP for External users or vice versa. To discuss this further, let's assume Service Provider assigns a first useable IP from a /30 subnet to its EDGE devices. First useable IP from a /30 subnet will be an ODD IP, similarly, second usable IP will be an EVEN number assigned to the customer external WAN interface. The ingress filtering at EDGE devices will only allow EVEN IP and deny ODD IP with few exceptions with the directly connected device at layer 3 IP protocol. To accomplish the IP filter list in the Service Provider EDGE device, SP need to create a policy that consist of a technique which uses network wild card mask. Shahid & Ahmed Expires July 25, 2011 [Page 5] Internet-Draft ingress filtering January 2011 3. Background Wildcard mask bits is one of the most important concept in IP access lists for ingress filtering. Routers use them to determine which bits in an address will be significant. Here is an example to filter the ODD IP of a 200.104.0.0/24 network Decimal IP address: 200.104.0.1 Binary IP address: 11001000.01101000.00000000.00000001 Decimal Mask: 0.0.0.254 Binary mask: 00000000.00000000.00000000.11111110 This wildcard mask requires that the first three octets and the final bit position of the forth octet match the IP address. Since the final bit position in the forth octet of the IP address is set to 1, all packets that the access list will permit or deny must have a 1 in the final bit position of the forth octet. Shahid & Ahmed Expires July 25, 2011 [Page 6] Internet-Draft ingress filtering January 2011 4. Securing Service Providers EDGE Devices By utilizing wildcard mask bits, ALL first useable IP address of a /30 subnet mask can be blocked from EXTERNAL address space with the exception of directly connected user. At the same time, second useable IP of /30 subnet mask will be reachable of the same subnet mask. In other words, all EVEN IPs will be reachable and accessible from external network and users. To apply the above policy of ingress filtering, let's assume following IPs and requirements: - Separate block of IP for INTERNAL infrastructure, in this example we are using 200.100.0.0/16. - Separate block of IP for EXTERNAL connectivity, in this example we are using 200.104.0.0/16. - First usable IP of a subnet mask /30 should be on assigned on Service Providers EDGE device and second useable IP for External users. The first category of IP block 200.100.0.0/16 is reserved for Service Provider INTERNAL infrastructure devices and that is normally denied and inaccessible from external sources. The second category of IP block 200.104.0.0/16 is reserved for service providers EDGE devices to connect with external user. (200.104.0.6/30) / CE2 / (200.104.0.1/30) / / / SP EDGE device#1<-->SP INTERNAL device<--->SP EDGE device#2 \ \ \ (200.104.0.5/30) \ CE1 \ (200.104.0.2/30) INTERNAL infrastructure address block (200.100.0.0/16) can be secured by simply denying the whole address block from external sources at Shahid & Ahmed Expires July 25, 2011 [Page 7] Internet-Draft ingress filtering January 2011 the perimeter of the network. In order to secure the EDGE devices facing external networks and users, the following below rules must be satisfied in order to apply ingress filtering: - Allow required routing and other management protocol from directly connected user to the service provider EDGE devices for local route processor handling. - Deny all types of external traffic destined to first useable IP of subnet mask /30 to external address space (200.104.0.0/16) To elaborate the above statement further, the following guidelines below will be used to configure the ingress filtering to protect the EXTERNAL address space (200.104.0.0/16) at the EDGE devices: 1. Point-to-point IP for external connectivity will be assigned from a dedicated EXTERNAL address space. 2. First useable IP of a point-to-point (/30 subnet mask) should assign to Service provider's edge device and second IP to external device (CE1) 3. CE1 should be allowed to send required routing and other management protocol (for example BGP and ICMP) packets to directly connected service provider device EDGE device # 1 (local processing traffic for the router) 4.After allowing restricted traffic as per above step for the route processor handling, all packets from external sources destined to first usable IP (which is ODD IP in this case) of aggregate EXTERNAL address spaced will be denied. 5.Finally allowing all type of transit traffic Same policy will be applied with all other external sources. Here is the further explanation of policy number 4. After allowing specific type traffic from directly connected device (as per policy number 3), all types of other external users and networks should not send data to ODD IPs of 200.104.0.0/16 block. In order to achieve this result, following IP address and subnet mask will be used: Decimal IP address: 200.104.0.1 Binary IP address: 11001000.01101000.00000000.00000001 Decimal Mask: 0.0.255.254 Binary Mask: 00000000.00000000.11111111.11111110 Shahid & Ahmed Expires July 25, 2011 [Page 8] Internet-Draft ingress filtering January 2011 The above wildcard mask requires that the first two octets and the final bit position of the fourth octet match the IP address. Since the final bit position in the fourth octet of the IP address is set to 1, all packets that the access list will deny must have a 1 in the final bit position of the forth octet, which is terminated to the service provider EDGE device. The configuration will be as follows: Ingress policy on EDGE device # 1 with CE1: ! Deny access to internal infrastructure address space [Deny ANY SOURCE IP to INTERNAL block 200.100.0.0/16] ! Permit ICMP from CE1 to EDGE device # 1 [Permit ICMP from host 200.104.1.2 to SP EDGE device 200.104.1.1] ! Permit BGP between CE1 and EDGE device # 1 [Permit BGP protocol between 200.104.1.2 AND 200.104.1.1] ! Deny access to ODD IPs assigned to SP EDGE devices [Deny ANY SOURCE IP to ODD IP of 200.104.0.0/16] ! Permit transit traffic. [Permit all types of traffic] Ingress policy on EDGE device # 2 with CE2: ! Deny access to internal infrastructure address space [Deny ANY SOURCE IP to INTERNAL block 200.100.0.0/16] ! Permit ICMP from CE2 to EDGE device # 2 [Permit ICMP from host 200.104.1.6 to SP EDGE device 200.104.1.5] ! Permit BGP between CE2 and EDGE device # 2 [Permit BGP protocol between 200.104.1.6 AND 200.104.1.5] ! Deny access to ODD IPs assigned to SP EDGE devices [Deny ANY SOURCE IP to ODD IP of 200.104.0.0/16] ! Permit transit traffic. [Permit all types of traffic] According to above policy, SP's edge device # 1 will accept ICMP and BGP packets coming from CE1 for the local Route Processor handling. There is no reachability from CE1 to other interface IPs assigned to Service provider EDGE devices. CE1 can access and reach other CE routers by using point-to-point address of 200.104.0.0/16 block. For example, if CE1 sends a packet to Service provider edge device # 2 interface (which is 200.104.0.5) Shahid & Ahmed Expires July 25, 2011 [Page 9] Internet-Draft ingress filtering January 2011 connected to CE2 the packet will be dropped as per ingress policy number 4, but on the other hand, CE1 can send all types of packet to CE2 (which is 200.104.0.6). Shahid & Ahmed Expires July 25, 2011 [Page 10] Internet-Draft ingress filtering January 2011 5. Summary The EVEN/ODD subnet mask bit in ingress filtering is a scalable way to secure the Infrastructure Network Layer, however, there are few constraints are faced such as separate block usage is imposed for a given environment, which may or may not be possible for a service provider. However, EVEN/ODD subnet mask bit provides a secure and flexible, yet a powerful gizmo in the realm of Infrastructure Network security and help to reduce the depletion of IPv4 address space. Same concept can be applied in case of using /31 subnet mask with the point-to-point link. Shahid & Ahmed Expires July 25, 2011 [Page 11] Internet-Draft ingress filtering January 2011 6. Security Considerations The primary intent of this document is to inherently increase security practices and awareness for the Internet community as a whole; as more Internet Providers and corporate network administrators implement ingress filtering, the opportunity for an attacker to service provider's edge devices addresses as an attack methodology will significantly lessen. Shahid & Ahmed Expires July 25, 2011 [Page 12] Internet-Draft ingress filtering January 2011 7. Appendix: Cisco Configuration Examples The configurations provided below are syntactical representations of the semantics described in the document and should be treated as non- normative. Refer to the Access Control List (ACL) document in the Cisco IOS Software Feature Guides for more information on the syntax and options available when configuring Access Control List, available at . Ingress policy configuration on EDGE device # 1 connected with CE1 !! [1] Deny access to internal infrastructure address space access-list 101 deny ip any 200.100.0.0 0.0.255.255 !! [2] Permit ICMP from CE1 to EDGE device # 1 access-list 101 permit icmp host 200.104.1.2 host 200.104.1.1 !! [3] Permit BGP between CE1 and EDGE device # 1 access-list 101 permit tcp host 200.104.1.2 host 200.104.1.1 bgp access-list 101 permit tcp host 200.104.1.2 eq bgp host 200.104.1.1 !! [4] Deny access to ODD IPs assigned to edge devices of Service Provider network access-list 101 deny ip any 200.104.0.1 0.0.255.254 !! [5] Permit transit traffic access-list 101 permit ip any any Ingress policy configuration on EDGE device # 2 with CE2 !! [1] Deny access to internal infrastructure address space access-list 102 deny ip any 200.100.0.0 0.0.255.255 !! [2] Permit ICMP from CE2 to EDGE device # 2 Access-list 102 permit icmp host 200.104.1.6 host 200.104.1.5 !! [3] Permit BGP between CE2 and EDGE device # 2 access-list 102 permit tcp host 200.104.1.6 host 200.104.1.5 bgp access-list 102 permit tcp host 200.104.1.6 eq bgp host 200.104.1.5 !! [4] Deny access to first useable IP ODD assigned to edge devices of Service Provider network access-list 102 deny ip any 200.104.0.1 0.0.255.254 !! [5] Permit transit traffic access-list 101 permit ip any any Shahid & Ahmed Expires July 25, 2011 [Page 13] Internet-Draft ingress filtering January 2011 8. Requirements notation 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]. Shahid & Ahmed Expires July 25, 2011 [Page 14] Internet-Draft ingress filtering January 2011 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Shahid & Ahmed Expires July 25, 2011 [Page 15] Internet-Draft ingress filtering January 2011 Authors' Addresses Ajaz Shahid Cisco Systems Inc A004-024 Al Safouh 2 Knowledge Village Dubai 532001 UAE Phone: +971 555 0101 33 Email: ajshahid@cisco.com Syed Ahmed Cisco Systems Inc A004-024 Al Safouh 2 Knowledge Village Dubai 532001 UAE Phone: +971 555 0116 50 Email: syghafoo@cisco.com Shahid & Ahmed Expires July 25, 2011 [Page 16]