ANCP Working Group L. Fan Internet-Draft B. Yuan Intended status: Standards Track B. Wu Expires: January 11, 2011 ZTE Corporation July 10, 2010 Network Anti-Attack for ANCP draft-fan-ancp-network-anti-attack-01 Abstract This document specifies an extension of Access Node Control Protocol to enforce security policy for network anti-attacking. An access router or NAS uses the proposed mechanism to send security policy to a layer 2 device which an attacking host may directly connects to. The solution proposed here can be used in either public access networks or enterprise networks. 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 January 11, 2011. 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 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 Fan, et al. Expires January 11, 2011 [Page 1] Internet-Draft Network Anti-Attack for ANCP July 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions and terminology . . . . . . . . . . . . . . . 4 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Case1: Control Message Anti-attack . . . . . . . . . . . . 5 3.3. Case2: Dos Anti-attack . . . . . . . . . . . . . . . . . . 5 3.4. Anti-attack Policies Application Case . . . . . . . . . . 6 3.4.1. MAC Black List Application . . . . . . . . . . . . . . 6 3.4.2. MAC White List Application . . . . . . . . . . . . . . 6 3.4.3. MAC Table Size Limitation Application . . . . . . . . 6 3.4.4. MAC Rate Limitation Application . . . . . . . . . . . 7 3.5. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 7 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Policy Configuration Message . . . . . . . . . . . . . . . 10 4.1.1. Policy Configuration Message Type 1 . . . . . . . . . 10 4.1.2. Policy Configuration Message Type 2 . . . . . . . . . 11 4.2. Configuration Response Message . . . . . . . . . . . . . . 11 4.3. Policy Release Message . . . . . . . . . . . . . . . . . . 13 4.4. Release Response Message . . . . . . . . . . . . . . . . . 15 5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 17 5.1. MAC-Black-List sub-TLV . . . . . . . . . . . . . . . . . . 17 5.2. MAC-White-List sub-TLV . . . . . . . . . . . . . . . . . . 18 5.3. MAC-Table-Size sub-TLV . . . . . . . . . . . . . . . . . . 19 5.4. MAC-Rate-Limitation sub-TLV . . . . . . . . . . . . . . . 19 5.5. Policy-Timer sub-TLV . . . . . . . . . . . . . . . . . . . 20 6. New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative references . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Fan, et al. Expires January 11, 2011 [Page 2] Internet-Draft Network Anti-Attack for ANCP July 2010 1. Introduction [I-D.ietf-ancp-framework] defines a framework and requirements for an Access Node control mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and subscriber-related operations. It also indicates that the dedicated security considerations are included in [I-D.ietf-ancp-security-threats]. [I-D.ietf-ancp-protocol] specifies a protocol for Access Node Control in broadband networks in line with the framework. The Access Node Control Protocol (ANCP) specified in [I-D.ietf-ancp-protocol] supports a number of use cases defined in [I-D.ietf-ancp-framework] such as the Access Topology Discovery use case, the Access Loop Configuration use case and the Remote Connectivity Test use case. However, it does not support the use cases for the security threats which are defined in [I-D.ietf-ancp-security-threats]. The present document specifies the extensions to the Access Node Control Protocol required for support of network anti-attack use case. Fan, et al. Expires January 11, 2011 [Page 3] Internet-Draft Network Anti-Attack for ANCP July 2010 2. 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 RFC2119. 2.1. Abbreviations 2.2. Definitions and terminology The expression "anti-attack policy" is used as a shorter way of saying: "the security policy that protecting the access router or NAS and the network behind it from the attacks which is launched by the subscribers". Fan, et al. Expires January 11, 2011 [Page 4] Internet-Draft Network Anti-Attack for ANCP July 2010 3. Use Case 3.1. Goals [I-D.ietf-ancp-security-threats] describes the security threats which might be launched by the subscribers, for example, DoS attacks (SYN flood, fraggle, smurf, etc.). In reality, there are other potential threats, such as scanning and snooping (address scanning, port scanning, tracert, etc.), malformed packet attacking (ping of death, teardrop, etc.), protocol control message attacking (PPP/DHCP Protocol Control Message attacking, etc.). These attacking actions could be detected on the NAS site with or without the help of external device. An appropriate solution is, the NAS sends an ANCP message which includes the corredponding network anti-attack policy to the AN when it detects the attack launched by the subscriber. 3.2. Case1: Control Message Anti-attack Sometimes, the attackers use massive amount of control messages to lunch the attacks towards the NAS, such as PPP/DHCP discover message. The control message could be a fake message, or just replicated from the original one. Usually, the NAS will send the attacking message to its internal control plane first. There will be a traffic management mechanism in the control plane that could be ware of the attacking event. The TM procedure will be carried out before the CPU processing the control messages. Since the TM usually just implements rate limitation to all the control messages of the same type, the legal messages will be discarded during the procedure. The discarding of legal control messages could be prevented by dynamic ACL generating and implementing on the NAS site, but there will be a large number of ACLs at the same time. When the attacking event is detected, the NAS could find out the attackers location by the information of the attacking message, such as option 82 which is attached by the Access Node. Then the NAS could use ANCP to send an anti-attack policy to the Access Node. It could be a MAC black list including the source MAC address/addresses of the attacking messages, a MAC white list includes the valid MAC addresses that belongs to the registered subscriber, or even a rate limitation of the access circuit. 3.3. Case2: Dos Anti-attack TCP semi-connection is a kind of SYN flood attacking tool, especially towards the application server. Currently, it was detected by an internal/external DPI function on the NAS site. Then the NAS will Fan, et al. Expires January 11, 2011 [Page 5] Internet-Draft Network Anti-Attack for ANCP July 2010 implement the anti-attack policy on itself. It is a centralized processing method which brings a heavy burden to the NAS, since there!_re always a lot of DOS attacks happening in the network. The NAS could use the ANCP to mitigate the processing stress of the massively concurrent SYN flood attacks. When the NAS detects the SYN flood attacking event and figure out the related access circuit by the attacking message, it could ask the Access Node to participating in the anti-attack procedure. It means that some of the anti-attack policy could be implemented on the Access Node, such as MAC black list and rate limitation. The layer 3 and upper layer policies will still be implemented on the NAS site. For scanning/snooping and malformed packet attacking, the ANCP solution is similar. In one word, for all the attacking methods that could be detected on the NAS site, whether by the control plane traffic management or by the internal/external DPI function, we could use ANCP to implement a better anti-attack solution. 3.4. Anti-attack Policies Application Case The anti-attack policy could be MAC black/white list, MAC rate limitation, MAC table size limitation and all other functions that are also currently available on the Access Node. We could use ANCP to dynamically enable these functions on the Access Node instead of statically configured by NMS/EMS. Some application cases will be listed in this section. 3.4.1. MAC Black List Application For discarding the attacks packets of a dedicated MAC address (e.g. SYN flood attacks and control message attacks towards the NAS), we could implement MAC black list on the Access Node through ANCP from the NAS. 3.4.2. MAC White List Application The NAS could send all the registered MAC addresses to the corresponding AN to enable the MAC white list function. So that the attacking messages with unregistered MAC will be discarding on the NAS site. 3.4.3. MAC Table Size Limitation Application A MAC table size limitation amount on the AN could efficiently reduce the attacking packets which use the fake MAC addresses. This Fan, et al. Expires January 11, 2011 [Page 6] Internet-Draft Network Anti-Attack for ANCP July 2010 function could be implemented on the enterprise use access line by ANCP. 3.4.4. MAC Rate Limitation Application A rate limitation function on the access line for a dedicated MAC address, but not for the whole access line, could limit the upstream flow of the MAC address, and not influence the others. 3.5. Message Flow In this use case, a Policy Configuration Message is sent by the NAS to the AN with or without a timer which indicates the enforcement duration. The AN uses a Configuration Response Message as a feedback to the NAS, includes success or failure as the running result. The NAS sends a Policy Release Message to stop the policy enforcement if there was no timer within the Policy Configuration Message. The AN will send a Release Response Message to the NAS when it receives the Policy Release Message or policy times out according to the timer. Figure 1 and Figure 2 illustrate the ANCP message exchange as well as the associated AN behavior. Fan, et al. Expires January 11, 2011 [Page 7] Internet-Draft Network Anti-Attack for ANCP July 2010 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| |CPE/RG | | AN |<-------------------->| NAS | +----------+ +-------+ +-----+ +-----+ | | | | | | | | | Attacking Flow | +======================================================>| | | | | | | | | | | | | | | Policy-Configuration | | | | (Type 1) | | | |<--------------------------| | | | | | | | | | | | | | | Configuration-Response | | | | | | | |-------------------------->| | | | | ~ ~ ~ ~ | | | Policy-Release | | | |<--------------------------| | | | | | | | | | | | | | | Realase-Response | | | |-------------------------->| | | | | Figure 1: Configure and Release Mode Fan, et al. Expires January 11, 2011 [Page 8] Internet-Draft Network Anti-Attack for ANCP July 2010 +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| |CPE/RG | | AN |<-------------------->| NAS | +----------+ +-------+ +-----+ +-----+ | | | | | | | | | Attacking Flow | +======================================================>| | | | | | | | | | | | | | | Policy-Configuration | | | | (Type 2) | | | |<--------------------------| | | | | | | | | | | | | | | Configuration-Response | | | | | | | |-------------------------->| | | | | ~ ~ ~ ~ | | | | | | | | | | | | | | Realase-Response | | | |-------------------------->| | | | | Figure 2: Configure with Timer Mode Fan, et al. Expires January 11, 2011 [Page 9] Internet-Draft Network Anti-Attack for ANCP July 2010 4. ANCP Messages This section defines new ANCP messages as well as procedures associated with the use of these messages. 4.1. Policy Configuration Message This section defines a message called the Policy Configuration Message. The Policy Configuration Message Type 1 is sent by the NAS to the AN. A Configuration Response Message will be sent from the AN to the NAS as a feedback. The Message Type for the Policy Configuration Message is 0xa0. The sender of a Policy Configuration Message MUST set the Result field to "0x00" meaning "Ignore". The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol] . 4.1.1. Policy Configuration Message Type 1 The payload of Policy Configuration Message Type 1 contains the following TLVs: o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol] . It MUST appear once and only once. It is encoded as specified in [I-D.ietf-ancp-protocol] and identifies the AN port subject to the request for anti-attack policy enforcement. o Command TLV: The Command TLV is defined in [I-D.ietf-ancp-protocol] . It MUST be present. It MAY appear multiple times. Each Command TLV contains one or more sub-TLVs, each of which includes an anti- attack policy directive for the target. The contents of the Command TLV for the Policy Configuration Message are defined in Figure 3 and subsequent text. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fan, et al. Expires January 11, 2011 [Page 10] Internet-Draft Network Anti-Attack for ANCP July 2010 Figure 3: Command TLV in Policy Configuration Message Type 1 Command Code: Command directive: 0x01 - Add (here means add to MAC Black/White List); 0x07 - Update (here means update MAC Table Size Limitation / Rate Limitation); 0x09 - Shut Down the Target. Command Length: Length in bytes of the Command includes all the sub-TLVs, but excludes the Command Code header and flags. Flags: 8 bit Flag field. Currently the following flags are defined: R - Retry Flag. The NAS will send again the Policy Configuration Message to the AN if it doesn!_t receive the Configuration Response Message from the AN. The R flag will be set to 1 in the retry message. The AN will send again the Configuration Response Message to the NAS when it receives the retry message. 4.1.2. Policy Configuration Message Type 2 Comparing with Policy Configuration Message Type 1, the only difference is that the Policy Configuration Message Type 2 has an additional Policy-Timer sub-TLV which indicates the policy enforcement duration, so that the NAS does not need to send a Policy Release Message to the AN. 4.2. Configuration Response Message This section defines a message called the Configuration Response Message. The Configuration Response Message is sent by the AN to the NAS, when the it receives a Policy Configuration Message Type 1 or Policy Configuration Message Type 2 Message from the NAS. The general purpose of the Configuration Response Message is to provide information on the success or failure to process a Policy Configuration Message received from the NAS. The Message Type for the Configuration Response Message is 0xa1. A Configuration Response Message MUST use the same ANCP Transaction ID as that in the message that it is responding to. The Success or Failure status is reported in the Result field of the ANCP header as described in section 5 of [I-D.ietf-ancp-protocol] . A Configuration Fan, et al. Expires January 11, 2011 [Page 11] Internet-Draft Network Anti-Attack for ANCP July 2010 Response Message indicating Success SHOULD simply consist only of the base ANCP header with no body, however the message MAY contain one or more TLVs that are meant to communicate any relevant information to an application. The payload of a Configuration Response Message indicating Failure MUST contain one or more Status-Info TLVs (0x12) (as defined in [I-D.ietf-ancp-protocol] ) followed by the Target TLV. Other TLVs MAY be present. A Configuration Response Message indicating Failure MUST be sent whenever a Policy Configuration Message cannot be fulfilled or results in an execution error. The Cmnd Nmbr parameter in the Status-Info TLV SHOULD be set to 0x00. The following values are defined for the Result Code field in the Status-Info TLV contained in a Configuration Response Message: 0x00 - Success 0x01 - Malformed message 0x02 - Command not supported 0x08 - Unrecognized Target 0x09 - Target down 0x10 - Transaction-id out of sequence 0x14 - Invalid MAC Table Size 0x15 - Invalid Rate Limitation Amount 0x17 - Invalid MAC Address An example of a failure message for an invalid address, including the Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV padding, is as follows: Fan, et al. Expires January 11, 2011 [Page 12] Internet-Draft Network Anti-Attack for ANCP July 2010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=a1 | 0x4 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-info-TLV=0x12 | Status-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Cmd Number | Error Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (padded to 4) if Length > 0 | +---------------------------------------------------------------+ | Target TLV=0x10 | Target-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Loop ID type | Access-Loop ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | circuit ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example of Configuration Response Message (Failure) Note that the Configuration Response Message may includes one or more Status-info TLVs. For example, part of the MAC addresses which are included in the Policy Configuration Message are invalid and succeeded to be add into the MAC black/white list, and the others are valid. Here we could use two status-info TLVs in the Configuration Response Message. 4.3. Policy Release Message This section defines a message called the Policy Release Message. The Policy Release Message is sent by the NAS to the AN. A Rlease Response Message will be sent from the AN to the NAS as a feedback. The Message Type for the Policy Configuration Message Type 1 is 0xa2. The sender of a Policy Release Message MUST set the Result field to "0x00" meaning "Ignore". The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol] . The payload of Policy Release Message contains the following TLVs: Fan, et al. Expires January 11, 2011 [Page 13] Internet-Draft Network Anti-Attack for ANCP July 2010 o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol] . It MUST appear once and only once. It is encoded as specified in [I-D.ietf-ancp-protocol] and identifies the AN port subject to the request for anti-attack policy release. o Command TLV: The Command TLV is defined in [I-D.ietf-ancp-protocol] . It MUST be present. It MAY appear multiple times. Each Command TLV contains one or more sub-TLVs, each of which includes an anti- attack policy directive for the target. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Command TLV in Policy Release Message Command Code: Command directive: 0x02 - Delete (here means delete in MAC Black/ White List); 0x03 - Delete All (here means delete all in MAC Black/ white List); 0x08 - Disable (here means disable MAC Table Size Limitation / Rate Limitation); 0x0a - Activate the Target. Command Length: Length in bytes of the Command includes all the Sub-TLVs, but excludes the Command Code header and flags. Flags: 8 bit Flag field. Currently the following flags are defined: R - Retry Flag. The NAS will send again the Policy Release Message to the AN if it doesn!_t receive the Release Response Message from the AN. The R flag will be set to 1 in the retry message. The AN will send again the Release Response Message to the NAS when it receives the retry message. Fan, et al. Expires January 11, 2011 [Page 14] Internet-Draft Network Anti-Attack for ANCP July 2010 4.4. Release Response Message This section defines a message called the Release Response Message. The Release Response Message is sent by the AN to the NAS, when the it receives a Configuration Release Message Type 1 or Policy Configuration Message Type 2 Message from the NAS. The general purpose of the Release Response Message is to provide information on the success or failure to process a Policy Release Message received from the NAS. The Message Type for the Release Response Message is 0xa3. A Release Response Message MUST use the same ANCP Transaction ID as that in the message that it is responding to. The Success or Failure status is reported in the Result field of the ANCP header as described in section 5 of [I-D.ietf-ancp-protocol] . A Release Response Message indicating Success SHOULD simply consist only of the base ANCP header with no body, however the message MAY contain one or more TLVs that are meant to communicate any relevant information to an application. The payload of a Release Response Message indicating Failure MUST contain a Status-Info TLV (0x12) (as defined in [I-D.ietf-ancp-protocol] ) followed by the Target TLV. Other TLVs MAY be present. A Release Response Message indicating Failure MUST be sent whenever a Policy Configuration Message cannot be fulfilled or results in an execution error. The Cmnd Nmbr parameter in the Status-Info TLV SHOULD be set to 0x00. The following values are defined for the Result Code field in the Status-Info TLV contained in a Release Response Status Message: 0x00 - Success 0x01 - Malformed message 0x02 - Command not supported 0x08 - Unrecognized Target 0x10 - Transaction-id out of sequence 0x16 - Fail to Activate the Target 0x18 - Invalid MAC Address 0x19 - The MAC Address does not exist in current black/white list An example of a failure message for an invalid address, including the Fan, et al. Expires January 11, 2011 [Page 15] Internet-Draft Network Anti-Attack for ANCP July 2010 Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV padding, is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=a1 | 0x4 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-info-TLV=0x12 | Status-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Cmd Number | Error Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (padded to 4) if Length > 0 | +---------------------------------------------------------------+ | Target TLV=0x10 | Target-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Loop ID type | Access-Loop ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | circuit ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Example of Release Response Message (Failure) Note that the Release Response Message may includes one or more Status-info TLVs. For example, part of the MAC addresses which are included in the Policy Configuration Message are in the current MAC black/white list, and the others does not exist in the current MAC black/white list . Here we could use two status-info TLVs in the Release Response Message. Fan, et al. Expires January 11, 2011 [Page 16] Internet-Draft Network Anti-Attack for ANCP July 2010 5. ANCP TLVs and Sub-TLVs This section defines ANCP TLVs and sub-TLVs. 5.1. MAC-Black-List sub-TLV This document defines the new MAC-Black-List sub-TLV. The MAC-Black-List sub-TLV MAY be included in a Command TLV of Policy Configuration Message or Policy Release message as specified in Section 4.1 and Section 4.3. The MAC-Black-List sub-TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type = MAC-Black-List | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr1 (continue) | MAC Addr2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr2 (continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: MAC-Black-List sub-TLV MAC-Black-List sub-TLV Type: sub-TLV (0xa0) indicating the contents to be a MAC-Black-List sub- TLV. MAC-Black-List sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. MAC Addrs: Contains all the MAC addresses that should be put into the MAC black list of the target. Fan, et al. Expires January 11, 2011 [Page 17] Internet-Draft Network Anti-Attack for ANCP July 2010 5.2. MAC-White-List sub-TLV This document defines the new MAC-White-List sub-TLV. The MAC-White-List sub-TLV MAY be included in a Command TLV of Policy Configuration Message or Policy Release message as specified in Section 4.1 and Section 4.3. The MAC-White-List sub-TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type = MAC-White-List | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr1 (continue) | MAC Addr2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr2 (continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: MAC-White-List sub-TLV MAC-White-List sub-TLV Type: sub-TLV (0xa0) indicating the contents to be a MAC-White-List sub- TLV. MAC-White-List sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. MAC Addrs: Contains all the MAC addresses that should be put into the MAC White list of the target. Fan, et al. Expires January 11, 2011 [Page 18] Internet-Draft Network Anti-Attack for ANCP July 2010 5.3. MAC-Table-Size sub-TLV This document defines the new MAC-Table-Size sub-TLV. The MAC-Table-Size sub-TLV MAY be included in a Command TLV of Policy Configuration Message as specified in Section 4.1. The MAC-Table-Size sub-TLV is illustrated below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type = MAC-Table-Size | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Table Size Amount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: MAC-Table-Size sub-TLV MAC-Table-Size sub-TLV Type: sub-TLV (0xa2) indicating the contents to be a MAC-Table-Size sub- TLV. MAC-Table-Size sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. MAC Table Size Amount: Indicates the required limitation of the MAC learning ability. 5.4. MAC-Rate-Limitation sub-TLV This document defines the new MAC-Rate-Limitation sub-TLV. The MAC-Rate-Limitation sub-TLV MAY be included in a Command TLV of Policy Configuration Message as specified in Section 4.1. The MAC-Rate-Limitation sub-TLV is illustrated below: Fan, et al. Expires January 11, 2011 [Page 19] Internet-Draft Network Anti-Attack for ANCP July 2010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = MAC-Rate-Limitation | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Addr (continue) | Rate Limitation Amount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rate Limitation Amount (continue)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MAC-Rate-Limitation sub-TLV MAC-Rate-Limitation sub-TLV Type: sub-TLV (0xa3) indicating the contents to be a MAC-Rate-Limitation sub-TLV. MAC-Rate-Limitation sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. MAC-Rate-Limitation MAC Addr: Indicates the dedicated MAC Addr of the packets which should be limited by rate. Rate Limitation Amount: Indicates the limitation of the forwarding performance (k bits per second). 5.5. Policy-Timer sub-TLV This document defines the new Policy-Timer sub-TLV. The Policy-Timer sub-TLV MAY be included in a Command TLV of Policy Configuration Message or Policy Release message Type 2 as specified in Section 4.1.2. The Policy-Timer sub-TLV is illustrated below: Fan, et al. Expires January 11, 2011 [Page 20] Internet-Draft Network Anti-Attack for ANCP July 2010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type = Policy-Timer | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Policy Timer Amount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Policy-Timer sub-TLV Policy-Timer sub-TLV Type: sub-TLV (0xa4) indicating the contents to be a Policy-Timer sub-TLV. Policy-Timer sub-TLV Length: Combined length in bytes of the data inside sub-TLV. Excludes the sub-TLV Header. Policy Timer Amount: Indicates the policy enforcement duration (seconds). Fan, et al. Expires January 11, 2011 [Page 21] Internet-Draft Network Anti-Attack for ANCP July 2010 6. New Capabilities [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism as well as a number of capabilities. This document defines the following generic Network Anti-Attack Capability Type: o Capability Type : Network Anti-Attack = 0x05 Length (in bytes) : 1 Capability Data (1 byte): The following values are defined: + 0x00: Reserved + 0x01: "MAC Black List" + 0x02: "MAC White List" + 0x03: "MAC Table Size Limitation" + 0x04: "MAC Rate Limitation" + 0x05: "Policy Timer" + other values: Reserved Both the NAS and the AN MUST advertise the Network Anti-Attack capability in their originated adjacency messages when they support it. Initially, they indicate the full set of anti-attack sub- capabilities that they respectively support by putting all the relative Capability Data values into the adjacency messages. Then, if a received adjacency message indicates that the originating device supports a smaller set of sub-capabilities than the device receiving the message, the receiving device will turn off the sub-capabilities that are not supported by the other device and will send an updated adjacency message with all the Capability Data values that now matches the ones of the other device. This process will eventually result in both sides agreeing on the common set of supported sub- capabilities. For example, if the NAS supports "MAC Black List", "MAC White List" and "MAC Table Size Limitation" while the AN only supports "MAC Black List" and "MAC White List", the NAS will initially advertise the Network Anti-Attack capability with a respective Capability Data of 0x01, 0x02 and 0x03. On receipt of the adjacency message from the AN, the NAS will turn off its "MAC Table Size Limitation" sub- Fan, et al. Expires January 11, 2011 [Page 22] Internet-Draft Network Anti-Attack for ANCP July 2010 capability on the adjacency and will send a new adjacency message with a Network Anti-Attack capability containing a Capability Data of 0x01 and 0x02. From there on, the NAS and AN agree to make use of (only) the "MAC Black List" and "MAC White List" sub-capabilities. Fan, et al. Expires January 11, 2011 [Page 23] Internet-Draft Network Anti-Attack for ANCP July 2010 7. Security Considerations This document discusses about the threats caused by the subscribers. The more security considerations of ANCP are discussed in [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. Fan, et al. Expires January 11, 2011 [Page 24] Internet-Draft Network Anti-Attack for ANCP July 2010 8. IANA Considerations This document defines the following additional values within the GSMPv3 Message Type Name Space registry: +--------------------------------+--------+---------------+ | Message | Number | Source | +--------------------------------+--------+---------------+ | Policy Configuration | a0 | This document | | | | | | Configuration Response | a1 | This document | | | | | | Policy Release | a2 | This document | | | | | | Release Response | a3 | This document | +--------------------------------+--------+---------------+ This document defines the following values for the ANCP Status-Info Result Code Registry : +----------------------------------------------+--------+-----------+ | Invalid MAC Table Size | 0x14 | This | | | | document | | | | | | Invalid Rate Limitation Amount | 0x15 | This | | | | document | | | | | | Fail to Activate the Target | 0x16 | This | | | | document | | | | | | Fail to Activate the Target | 0x17 | This | | | | document | | | | | | Invalid MAC Address | 0x18 | This | | | | document | | | | | | The MAC Address does not exist in current | 0x19 | This | | black/white list | | document | +----------------------------------------------+--------+-----------+ This document defines the following values for the ANCP Command Code registry: Fan, et al. Expires January 11, 2011 [Page 25] Internet-Draft Network Anti-Attack for ANCP July 2010 +-------------------------------------+----------------+------------+ | Command Code Directive Name | Command Code | Reference | | | Value | | +-------------------------------------+----------------+------------+ | Update | 0x07 | This | | | | document | | | | | | Disable | 0x08 | This | | | | document | | | | | | Shutdown the Target | 0x09 | This | | | | document | | | | | | Activate the Target | 0x0a | This | | | | document | +-------------------------------------+----------------+------------+ This document defines the following values for the ANCP sub-TLV Type registry: +--------------------+-----------+---------------+ | sub-TLV Name | Type Code | Reference | +--------------------+-----------+---------------+ | MAC-Black-List | 0xa0 | This document | | | | | | MAC-White-List | 0xa1 | This document | | | | | | MAC-Table-Size | 0xa2 | This document | | | | | | MAC-Rate- | 0xa3 | This document | | Limitation | | | | | | | | Policy-Timer | 0xa4 | This document | +--------------------+-----------+---------------+ This document defines the following values for the ANCP Capability Type registry: Fan, et al. Expires January 11, 2011 [Page 26] Internet-Draft Network Anti-Attack for ANCP July 2010 +-------------------------------------+----------------+------------+ | Command Code Directive Name | Command Code | Reference | | | Value | | +-------------------------------------+----------------+------------+ | Network-Anti-Attack | 0x05 | This | | | | document | +-------------------------------------+----------------+------------+ This document defines the following values to the ANCP Capability Type registry: +-------------------------------------+----------------+------------+ | Command Code Directive Name | Command Code | Reference | | | Value | | +-------------------------------------+----------------+------------+ | MAC Black List | 0x01 | This | | | | document | | | | | | MAC White List | 0x02 | This | | | | document | | | | | | MAC Table Size Limitation | 0x03 | This | | | | document | | | | | | MAC Rate Limitation | 0x04 | This | | | | document | | | | | | Policy Timer | 0x05 | This | | | | document | +-------------------------------------+----------------+------------+ Fan, et al. Expires January 11, 2011 [Page 27] Internet-Draft Network Anti-Attack for ANCP July 2010 9. Acknowledgement The authors would like to thank everyone that has provided comments or input to this document. We are longing for more comments. Fan, et al. Expires January 11, 2011 [Page 28] Internet-Draft Network Anti-Attack for ANCP July 2010 10. References 10.1. Normative references [I-D.ietf-ancp-framework] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", October 2009. [I-D.ietf-ancp-protocol] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, N., and R. Maglione, "Protocol for Access Node Control Mechanism in Broadband Networks", November 2009. [I-D.ietf-ancp-security-threats] Moustafa, H., Tschofenig, H., and S. Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", July 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [[I-D. ietf-ancp-mc-extensions] Faucheur, F., Maglione, R., and T. Taylor, "Additional Multicast Control Extensions for ANCP", October 2009. 10.2. Informative References [[TR-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control Mechanism for Broadband Multi-Service Architectures", December 2008. Fan, et al. Expires January 11, 2011 [Page 29] Internet-Draft Network Anti-Attack for ANCP July 2010 Authors' Addresses Liang Fan ZTE Corporation 4F,RD Building 2,Zijinghua Road 68 Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52878135 Email: fan.liang2@zte.com.cn Bo Yuan ZTE Corporation 4F,RD Building 1,Zijinghua Road 68 Yuhuatai District,Nanjing 210012 P.R.China Phone: Email: yuan.bo3@zte.com.cn Bo Wu ZTE Corporation 4F,RD Building 2,Zijinghua Road 68 Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877276 Email: wu.bo@zte.com.cn Fan, et al. Expires January 11, 2011 [Page 30]