idnits 2.17.1 draft-singh-capwap-ctp-01.txt: -(971): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1627): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1630): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1668): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1756): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 1765 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 21 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2005) is 6949 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 294 -- Looks like a reference, but probably isn't: 'SNMP' on line 557 ** Downref: Normative reference to an Informational RFC: RFC 3990 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '5') Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Group 3 Internet Draft I. Singh 4 Document: draft-singh-capwap-ctp-01.txt P. Francisco 5 K. Pakulski 6 Chantry Networks 7 F. Backes 8 AutoCell Laboratories 9 Expires: October 2005 April 2005 11 CAPWAP Tunneling Protocol (CTP) 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 3 of RFC3667. By submitting this Internet- 17 Draft, each author represents that any applicable patent or other 18 IPR claims of which he or she is aware have been or will be 19 disclosed, and any of which he or she become aware will be 20 disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 4, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 With the overwhelming choice of proprietary implementations of 47 centralized control and management of wireless access points and 48 access controllers there is a great demand for a standard protocol 49 and architecture that enables the deployment of large scale wireless 50 networks. 52 This document describes the CAPWAP Tunneling Protocol, a protocol 53 that allows for the centralized control and provisioning of a large 54 number of wireless access points from access controllers. It is 55 supported by an architecture where the MAC layer of the RF technology 56 is terminated within the AP. This allows for the protocol to be 57 extensible to multiple radio technologies. It assumes an IP 58 connection between the access points and access controllers and has 59 signaling primitives to enable wireless station mobility between 60 access points. Therefore, seamless Layer 3 subnet mobility is 61 seamlessly enabled by this protocol. 63 Table of Contents 65 1. Definitions....................................................4 66 1.1 Conventions used in this document..........................4 67 1.2 Terminology................................................4 68 2. Introduction...................................................4 69 2.1 Out of scope...............................................6 70 2.1.1 Secure discovery of AP and AC.........................6 71 2.1.2 AP image management...................................6 72 2.1.3 Multiple AC mobility..................................7 73 3. Protocol Overview..............................................7 74 3.1 Control and Status Messages................................7 75 3.2 Configuration and Statistics messages......................7 76 3.3 Data Messages..............................................8 77 4. CTP Packets....................................................8 78 4.1 CTP Header format..........................................8 79 4.2 Messages...................................................9 80 4.3 Message Payloads..........................................10 81 5. Message descriptions..........................................13 82 5.1 Message State Control.....................................13 83 5.2 Control and Status messages...............................13 84 5.2.1 CTP_Reg-Req..........................................13 85 5.2.2 CTP Reg-Rsp..........................................14 86 5.2.3 CTP Auth-Req.........................................14 87 5.2.4 CTP Auth-Rsp.........................................15 88 5.2.5 CTP SW-Update-Req....................................15 89 5.2.6 CTP SW-Update-Rsp....................................16 90 5.2.7 CTP_Set-State-Req....................................16 91 5.2.8 CTP_Set-State-Rsp....................................17 92 5.2.9 CTP Poll-Req.........................................17 93 5.2.10 CTP Poll-Rsp........................................18 94 5.2.11 CTP_MU-Connect-Req..................................18 95 5.2.12 CTP_MU-Connect-Rsp..................................18 96 5.2.13 CTP_MU-Disconnect-Req...............................19 97 5.2.14 CTP_MU-Disconnect-Rsp...............................19 98 5.2.15 CTP_MU-Disconnect-Nfy...............................20 99 5.2.16 CTP MU-Authenticate-Req.............................20 100 5.2.17 CTP MU-Authenticate-Rsp.............................20 101 5.3 Configuration and Statistics messages.....................21 102 5.3.1 CTP Cap-Req..........................................21 103 5.3.2 CTP Cap-Rsp..........................................24 104 5.3.3 CTP Config-Req.......................................25 105 5.3.4 CTP Config-Rsp.......................................25 106 5.3.5 CTP Config-Ack.......................................25 107 5.3.6 CTP_Config-Status-Notify.............................26 108 5.3.7 CTP_Stats-Notify.....................................26 109 5.3.8 CTP Stats-Req........................................26 110 5.3.9 CTP Stats-Rsp........................................27 111 5.3.10 Configuration and Statistics........................27 112 5.4 CTP_Data Messages.........................................27 113 5.4.1 CTP_Data.............................................28 114 6. State Machines................................................29 115 6.1 Init......................................................29 116 6.2 Control Channel Establishment.............................29 117 6.3 Active State..............................................30 118 6.4 Standby State.............................................30 119 7. Authentication, Encryption and Session Key generation.........30 120 7.1 Authentication............................................30 121 7.2 Encryption................................................33 122 7.3 Session Key refresh and generation........................35 123 8. Security considerations.......................................36 124 9. References....................................................36 125 10. Author's Addresses...........................................37 126 Intellectual Property and Copyright Stattements .............37 128 1. Definitions 130 1.1 Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [1] 136 1.2 Terminology 138 AP � Access Point - The network device that includes both the 139 wireless termination point as well as the implementation of a 140 specific radio technology management layer. 142 AC - Access Controller - A centralized network entity that controls, 143 configures and manages one or more than one APs. 145 MU - Mobile Unit - A wireless device which is also an IP node capable 146 of dynamic change in its association with an Access Point. 148 2. Introduction 150 The rapid pace with which wireless networks are being deployed in the 151 home, enterprise and carrier industries has led to the proliferation 152 of proprietary solutions which attempt to address problems associated 153 with large scale wireless installations. The main issues plaguing 154 802.11 wireless networks, for example, are described in [2] and can 155 be summarized as: the manageability of large numbers of APs (Access 156 Points); the secure and bulk provisioning, monitoring, and control of 157 APs; and policy control and enforcement of MU (Mobile Units) data 158 flows and policies. 160 One of the key problems with deploying large scale wireless networks 161 is that the infrastructure needs to scale to meet both geographic 162 coverage as well as client density requirements. CAPWAP Tunneling 163 Protocol (CTP) addresses these challenges by minimizing configuration 164 of the wired infrastructure to accommodate the wireless network. 166 CTP provides both centralized configuration and operational control 167 for wireless networks, and in doing so, provides centralized security 168 and policy management. 170 This solution has been currently focused towards 802.11 networks. 171 However, CTP is independent of the layer 2 wireless standard because 172 it assumes that the MAC layer of the wireless technology is fully 173 implemented in the AP. The control channel binding between the AP and 174 AC provides for all the necessary signaling to facilitate MU 175 connection, mobility, and even RF resource management. Thus, it is 176 possible to use CTP to offer IP network services to wireless users 177 independent of the underlying wireless technology (e.g. 802.11, 178 802.15, or 802.16). 180 CTP involves one or more Access Points (APs) connected to one or more 181 Access Controllers (ACs). The network connectivity between the APs 182 and ACs is primarily through a Layer 3 routed network. However, 183 switched Layer 2 or directly connected network topologies are also 184 supported. Figure 1 shows the typical network topology of AP and AC 185 placement in a CTP network. However, since it is assumed that the AP 186 and AC are IP addressable direct connect or L2 connect is also 187 supported. 189 +-------+-------+ 190 | AC | 191 +-------+-------+ 192 | 193 --------+------ LAN 194 | 195 +-------+-------+ 196 | | 197 +-------+-------+ 198 | 199 -----+--+--+--- LAN 200 | | 201 +---+ +---+ 202 | | 203 +--+--+ +--+--+ 204 | AP | | AP | 205 +--+--+ +--+--+ 207 Figure 1 - Topology of AP and AC placement 209 CTP interacts directly with the MAC management entity to monitor and 210 control configuration and wireless connections. CTP tunnels data 211 traffic as 802.3 traffic to the AP and uses the L2 Bridge to pass 212 data to the MAC. Optionally, data traffic can be passed directly to 213 the AP, independent of a CTP data connection. This mode of operation 214 is fully controlled by the AC rather than being an inherent property 215 of the AP. There has been wide interest in this deployment model in 216 the case where the link between the AC and the AP is a slow WAN link, 217 for example. By bridging the MU data traffic locally at the AP's 218 network, and still controlling the authentication centrally via the 219 AC, the user is able to forgo the possibility of the data traffic 220 having to traverse the slow WAN link upstream and then again 221 downstream to access, for example, a local printer. In this 222 centralized architecture solution of CTP, the layer 2 wireless 223 termination point and the MAC layer are fully implemented in the AP 224 as shown in Figure 2, which enables this type of feature. 226 +--+--+ +----+------+ 227 Control <===>| | | | 228 | CTP |<===========>|WirelessMAC| 229 Data <--->| | | | 230 +--+--+ +----+------+ 231 ^ ^ 232 | +-----------+ | 233 | | | | 234 Data (optional) <-------+--->| L2 bridge |<---+ 235 | | 236 +-----------+ 238 Figure 2 - CTP and MAC interaction in an AP 240 2.1 Out of scope 242 The following areas are out of scope for this version of the 243 protocol. 245 2.1.1 Secure discovery of AP and AC. 247 Rather than specify a brand new secure discovery mechanism for APs 248 and ACs within this protocol, CTP specifies the context and security 249 credentials that are required to register APs into ACs. All AP 250 implementations of CTP MUST provide a method to statically configure 251 the IP address(es) of the AC to be stored in the non-volatile RAM of 252 the AP. 254 Other methods for automatic discovery that MAY be used by 255 implementations of CTP are: SLP, DNS name resolution, and DHCP 256 options for AC IP address(es). The mechanism by which these methods 257 are incorporated into CTP is out of scope for this document but is a 258 worthwhile task for the working group that takes on this work. 260 2.1.2 AP image management. 262 A conscious decision in the design of this protocol excluded the 263 implementation of an AP image management system. However, CTP 264 provides triggers for software upgrade, ie. a message to indicate 265 software version and a message to command the AP to initiate software 266 upgrade. The actual protocol and mechanism for secure software 267 download has been deemed out of scope for the protocol and beyond 268 what the protocol was intended for. 270 2.1.3 Multiple AC mobility 272 This version of CTP does not include the details of support for 273 multi-AC control over APs for the purposes of multi-AC MU mobility. 274 However, the reserved message types and the capability exchange phase 275 may be used to facilitate the setting up of intra-AC tunnels. 277 3. Protocol Overview 279 CTP is a generic protocol that defines a mechanism for the control 280 and provisioning of wireless APs through centralized ACs. In 281 addition, it provides a mechanism to optionally tunnel the mobile 282 client data between the AP and AC. 284 There are two types of CTP packet headers: 286 a) Control: these messages allow the AC to provision and control 287 the APs and MU session state and further contain messages that 288 consist of configuration, statistics and state management. 290 b) Data: an optional aspect of the protocol that allows MU data 291 packets tunneled between the AP and the AC. 293 The CTP messages between APs and ACs are delivered by a UDP transport 294 and the UDP port number is [TBD]. The message types of this protocol 295 are classified into three distinct categories: 297 o Control and Status messages 298 o Configuration and Statistics messages 299 o Data messages. 301 3.1 Control and Status Messages 303 The set of control messages of CTP provides a mechanism for an AP to 304 register itself with the AC and to interact with the MU session 305 management operations of the AC. Primarily this set is utilized by 306 the AP to request session association with the AC, configuration 307 information, and to provide the mechanism and notification of MU 308 connection to the AC. The AC uses this message set to acknowledge AP 309 and MU session establishment and to explicitly control both AP and MU 310 session operational state (such as AP state changes, AP and MU 311 session disconnection, etc.) 313 3.2 Configuration and Statistics messages 315 This logical set of messages exchanged between AP and AC is primarily 316 intended for the provisioning of the AP via a capabilities exchange 317 and configuration message set. This message set also includes a 318 means for the AP to provide periodic status notifications of current 319 operational state, statistics information such as wireless and wired 320 statistics, security alerts, etc. 322 3.3 Data Messages 324 The CTP-Data message is the only message in this set. Its purpose is 325 to carry encapsulated frames associated with a registered MU. This 326 message type utilizes the Policy field of the message header to 327 provide user based, post authentication policy enforcement on a per 328 packet basis. This message type applies to actual MU client data and 329 does not include MU association, authentication and MU session 330 management messages as those operations are explicitly represented 331 though specific control messages. 333 It must be noted that the protocol allows for the data path to not 334 have to traverse the AC. In that case, no policy can be applied on a 335 per user basis centrally. 337 4. CTP Packets 339 It is assumed that the AP and AC source and destination information 340 is available in the transport layer headers. As such, it is not 341 indicated below. 343 4.1 CTP Header format 345 Figure 3 describes the CTP message header format: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Ver |0|0|0|P|E| Type | Policy | Reserved | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Session Id. | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Message Payload... 355 +-+-+-+-+ 357 Figure 3 - CTP Header format 359 Ver Field 361 This field identifies the version of the protocol. It is 3 bits of 362 data. For this specification the version field is 0. 364 Flags Field 365 This field is a bitmask of 5 bits that represents special CTP 366 processing. Bits 3, 4, and 5 are undefined and MUST be zero (0). 367 Bit #6 and #7 as follows: 369 Bit P � Payload Header 370 1 indicates that the CTP header is followed by a CTP payload 371 header (see 5.3.1) 372 0 indicates that there is no CTP payload header 374 Bit E - Data path Encryption 375 1 indicates that the CTP-Data message type data is encrypted 376 0 indicates that the CTP-Data message is in the clear 378 Type Field 380 This is a 1 byte field that identifies the message type. The message 381 types are identified in Section 4.2. 383 Policy Field 385 This is a 1 byte field that represents policy to be assigned and 386 enforced. The definition of this policy field is dependent on the 387 message type. For example, if the message type is CTP-Data (defined 388 below) the Policy field corresponds to QOS policy for the MU data 389 above and beyond the QOS TOS markings or DiffServ markings that may 390 have been applied to the end-to-end user data. If the message type 391 is not CTP-Data, then this field is not interpreted by either AP or 392 AC and MUST be set to all zeros. 394 Reserved 396 Reserved for future use. MUST be set to zero (0). 398 Session ID Field 400 This is a 2 byte field that includes a unique session identifier 401 provisioned by the AC after successful authentication. 403 Length Field 405 This is a 2 byte field that indicates the length of payload (excludes 406 the header length). 408 4.2 Messages 409 The following message types are defined in CTP: 410 Message Type 411 ----------------------------- 413 Reserved 0-1 414 Reg-Req 2 415 Reg-Rsp 3 416 Auth-Req 4 417 Auth-Rsp 5 418 SW-Update-Req 6 419 SW-Update-Rsp 7 420 Config-Req 8 421 Config-Rsp 9 422 Config-Ack 10 423 Conf-Status-Notify 11 424 Set-State-Req 12 425 Set-State-Rsp 13 426 Stats-Notify 14 427 CTP-Data 15 428 Poll-Req 16 429 Poll-Rsp 17 430 Stats-Req 18 431 Stats-Rsp 19 432 Cap-Req 20 433 Cap-Rsp 21 434 Reserved 22-50 435 MU-Connect-Req 51 436 MU-Connect-Rsp 52 437 MU-Disconnect-Req 53 438 MU-Disconnect-Rsp 54 439 MU-Authenticate-Req 55 440 MU-Authenticate-Rsp 56 441 MU-Disconnect-Nfy 57 442 Reserved 58-255 444 4.3 Message Payloads 446 Each message type defined above may or may not have a corresponding 447 CTP message payload. The payload contents are exchanged with the AC 448 through the exchange of relevant Type-Length-Value (TLV) elements. 450 Each element is encoded as follows: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Value... 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Type 463 One of the element types as defined below 465 Length 466 Total length of the type + length + value fields 468 Value 469 Value 471 Several elements may be combined in sequence to provide a full 472 payload definition. 474 Note: In order to properly utilize TLVs, the length field of the CTP 475 header must be properly calculated and includes the sum of the length 476 fields of all TLVs in the payload. 478 The following provides a list of TLVs as defined in this version of 479 the protocol: 481 Definition Type Length Description 482 (bytes) 483 --------------------------------------------------------------------- 485 STATUS 1 4 Explicit indication of the 486 response to requests messages. 487 Values for STATUS are the same 488 across all messages: 489 0 - Undefined 490 1 - Success 491 2 � Failure 493 SWVersion 2 Variable ASCII text representation of 494 the AP software version 495 number. 497 AP SERIAL_NUMBER 3 16 Unique ASCII representation of 498 the Serial number of AP. This 499 serial number of the AP must 500 be a priori available to the 501 AC. Method of getting this 502 serial number to the AC is out 503 of scope for this document. 505 AP REG_CHALLENGE 4 16 A 16 byte random challenge 506 generated by the AC, to be 507 used by AP upon registration. 509 AP REG_RESPONSE 5 16 A 16 byte AP calculated 510 response to AP REG CHALLENGE 512 AC_IPADDR LIST 6 Variable List of AC IP addresses with 513 which said AP should attempt 514 to connect 516 CONFIG 7 variable Value contains a [SNMP] set of 517 OIDs of encoded configuration 518 elements 520 AC REG CHALLENGE 8 16 A 16 byte random challenge 521 generated by the AP, to be 522 used by AC upon registration 523 request. 525 AC REG_RESPONSE 9 16 A 16 byte AC calculated 526 response to AC REG CHALLENGE 528 NETWORK ID 10 4 Network ID with which a given 529 radio in the AP is associated. 530 This value is unique as it is 531 calculated by the AC upon the 532 provisioning phase of the AP 533 and provided to it in the 534 Config-Rsp message. In the 535 case of 802.11 radio 536 technology, this is the 537 Extended Service Set (ESS) to 538 which the AP belongs. This is 539 a 32 bit integer represent- 540 ation of the ESS. For other 541 radio technologies, this is a 542 unique value representing the 543 network that the radio is a 544 member of. 546 AP_STATE 11 4 Value contains indication of 547 AP state: 548 0=Standby 549 1=Active 550 2=Reset 552 SESSION_KEY 12 19 Encrypted session encryption 553 key to secure AP to/from AC 554 communications. 556 STATS 13 Variable Value contains a 557 [SNMP] set of OIDs of encoded 558 statistics elements 560 RADIO ID 15 1 Index number of the radio as 561 learnt during the Capabilities 562 exchange. 564 REQ ID 16 1 Message identification to 565 match request and response 566 messages. 568 AUTH_PAYLOAD 17 Variable Payload TLV to include 569 Encapsulation of MU 570 Authentication/Authorization 571 Messages. Typically EAP 572 frames. 574 CERTIFICATE 18 Variable Digital certificate 575 credentials of the AP or AC 577 5. Message descriptions 579 5.1 Message State Control 581 Unless otherwise stated, every message that is a "request" type 582 includes a REQ ID payload inserted by the sender of the message. 583 This is sent so as to aid in the match of messages that are received 584 as "responses". After the transmission of each request, the source 585 will wait up to 2 seconds for the reception of the response. If a 586 response is not received, the source will retransmit the packet up to 587 3 times. If after 3 attempts a response is still not received the 588 source aborts the session and resets its state machine. If the 589 source is the AP, the AP shall resume registration operations. 590 Correspondingly the AC will simply delete the AP session from its 591 database and drop all packets which are from unregistered APs. 593 5.2 Control and Status messages 595 5.2.1 CTP_Reg-Req 597 This message is used by the AP to request registration with the AC. 599 This message is initiated by the AP after successful secure discovery 600 and following the hardware and software initialization sequence of 601 the AP. The Session ID of this message is set to 0x0000 because the 602 AC will subsequently assign a Session ID upon successful 603 authentication. This message requires a mandatory payload, namely 604 "AP Serial Number". 606 HEADER 607 Type = 2 608 SessionID = 0x0000 610 PAYLOAD 611 REQ ID 612 AP SERIAL NUMBER 614 5.2.2 CTP Reg-Rsp 616 This message is sent by the AC to an AP to indicate that it has 617 conditionally accepted the AP's registration request based on knowing 618 who the AP is and based on the provided serial number. If the STATUS 619 = Success, then this message will also contain an AP REG CHALLENGE 620 payload. This is a randomly generated 16 byte challenge to the AP. 622 HEADER 623 Type = 3 624 SessionID = 0x0 626 PAYLOAD 627 REQ ID = from the corresponding Reg-Req message 628 STATUS = Success (1) or Failure (2) based on the known AP database 629 in the AC 630 AP REG CHALLENGE 632 5.2.3 CTP Auth-Req 634 This message is sent by the AP to begin the authentication phase of 635 the connection establishment with the AC. It contains the AP serial 636 number, an AP REG RESPONSE payload, the AP's digital certificate 637 (which contains the AP's public key) and a 16 byte random challenge 638 to the AC. Note that the SessionID field in the packet header is 639 still zero. 641 HEADER 642 Type = 4 643 SessionID = 0x0 645 PAYLOAD 646 REQ ID 647 AP_SERIAL_NUMBER 648 CERTIFICATE 649 AP REG RESPONSE = Digital Signature of the concatenation of the AP 650 SERIAL NUMBER and the AP REG CHALLENGE (from the Reg-Rsp message) 651 AC_REG_CHALLENGE = 16 byte random number challenge sent to 652 authenticate the AC. 654 The response is calculated by the AP and is verified by the AC. For 655 details on the calculation of challenge and response, see Section 7 657 5.2.4 CTP Auth-Rsp 659 This message is sent by the AC to the AP as an indication of the 660 success or failure of the authentication phase. The AP is only 661 considered to have successfully associated with the AC if both 662 registration and authentication phases complete successfully. 664 HEADER 665 Type = 5 666 SessionID = 16 byte unsigned value generated by the AC. This is 667 set appropriately in this message if the authentication phase was 668 successful. After this message, the AP should use this Session ID in 669 all subsequent messages. 671 PAYLOAD 672 REQ ID = from the corresponding Auth-Req message 673 STATUS = Success (1) if the AP's digital certificate was 674 successfully verified and the AP REG RESPONSE was verified. 675 CERTIFICATE 676 AC REG RESPONSE = Digital Signature of the concatenation of the AP 677 SERIAL NUMBER and the AC REG CHALLENGE (from the Auth-Req message) 678 SESSION KEY = An encrypted payload of the AC generated CTP session 679 key. This is encrypted using the public key of the AP as received in 680 the AP's digital certificate from the Auth-Req message. 682 The STATUS payload indicates whether authentication and registration 683 was processed correctly. If so, Session ID for registration is 684 explicitly provided in the message header. 686 5.2.5 CTP SW-Update-Req 688 This message is sent by the AP to ask the AC whether it should 689 upgrade its own software or not. It simply needs to provide its 690 current software version to the AC. 692 This message MAY also be sent by the AC to the AP which is a command 693 indication for the AP to stop operations and upgrade its software. 695 HEADER 696 Type = 6 697 SessionID = the assigned ID as received in the Auth-Rsp message. 699 PAYLOAD 700 REQ ID 701 SWVersion = Variable length ASCII text specifying the current 702 running software on the AP. 704 5.2.6 CTP SW-Update-Rsp 706 This message is sent by the AC to signal the AP to upgrade its 707 software or by the AP to the AC to indicate to confirm that it has 708 received the upgrade request. When the corresponding request is 709 issued by the AP, the AC will check the SWVersion payload received in 710 the Software-Upgrade-Req for the AP and send a response based on a 711 match. The interpretation of the SWVersion payload is implementation 712 specific. The response by the AC is either "Yes" or "No" which is 713 interpreted through the STATUS payload. If the response by the AC 714 indicates a failure the AP must abandon the registration stage, 715 upgrade its software to the version indicated by the AC. The method 716 by which the software image is exchanged is outside of the scope of 717 this protocol. 719 When the corresponding request is issued by the AC, the AP will 720 simply confirm the reception of the request and abandon it�s 721 connected state in order to perform the upgrade. 723 HEADER 724 Type = 7 725 SessionID = the assigned ID as received in the Auth-Rsp message. 727 PAYLOAD 728 REQ ID = from the corresponding SW-Update-Req message 729 STATUS = [Success/Don't Upgrade (1) | Failure/Upgrade (2)] 730 SWVersion [On Failure] = Variable length ASCII text specifying the 731 correct software version the AP should have in order to complete the 732 session registration with the AC. 734 5.2.7 CTP_Set-State-Req 736 This message is sent by the AC to modify the operational state of the 737 AP. For example, at some point during an established connection it 738 may be necessary to instruct an AP to go to STANDBY state or initiate 739 a reboot/reset of its state machine. These states are usually 740 entered upon user request 742 The following states are defined and apply to the AP: 744 ACTIVE 746 Indication to the AP that it should exit standby state and should 747 resume full active network state including enabling it�s RF 748 interfaces. This is the default state of the AP after successful 749 configuration phase. 751 STANDBY 753 This signifies a state where the AP, although connected to the AC, is 754 in a state whereby no RF connection is allowed. It may be a sent to 755 the AP upon user request. 757 RESET 759 This is used as a command to the AP to change state to initialization 760 state. This may be sent to the AP upon user request or upon failure 761 of any of the phases of the control channel establishment. 763 HEADER 764 Type = 12 765 SessionID = AP session id from registration 767 PAYLOAD 768 REQ ID 769 AP_STATE = [STANDBY(0) | ACTIVE(1) | RESET(2)] 771 5.2.8 CTP_Set-State-Rsp 773 This message is sent by the AP to indicate to the AC that it has 774 changed its operational state as requested. 776 HEADER 777 Type = 13 778 SessionID = AP session id from registration 780 PAYLOAD 781 REQUEST ID = Same ID that was received in the Set-State-Req 782 message. 783 STATUS = [Success (1) | Failure (2)] 784 AP_STATE = [STANDBY(0) | ACTIVE(1) | RESET(2)] 786 The RESET(2) state assumes that the AP would have reset its 787 operations after sending out this message. 789 5.2.9 CTP Poll-Req 791 This message is the keepalive mechanism for the CTP control channel. 792 This is sent by the AP to the AC. The default send frequency for 793 this message is 5 seconds. If no response is received from the AC 794 after sending this message 6 times in a row, then the AP should tear 795 down its CTP control channel state and reattempt to connect to the 796 AC. These values are considered to be defaults. An AP 797 implementation MAY choose to change these values for suitability to 798 network deployment conditions. 800 HEADER 801 Type = 16 802 SessionID = AP session id from registration 804 PAYLOAD 805 REQ ID = ID representing the Poll-Req. Incremented until a 806 corresponding Poll-Rsp is received. 808 5.2.10 CTP Poll-Rsp 810 This message is the keepalive mechanism for the CTP control channel. 811 This is sent by the AC in response to a CTP Poll-Req message received 812 from the AP. The AC SHOULD detect the loss of connectivity with the 813 AP based on the receipt of a Poll-Req message. 815 HEADER 816 Type = 17 817 SessionID = AP session id from registration 819 PAYLOAD 820 REQ ID = ID corresponding to the Poll-Req received. 822 5.2.11 CTP_MU-Connect-Req 824 This message is sent by the AP to relay an association request 825 received from an MU to the AC. 827 HEADER 828 Type = 51 829 SessionID = AP session id from registration 831 PAYLOAD 832 REQ ID 833 MU-MAC-Address = MAC Address corresponding to the associating MU 834 NETWORK ID = Network identification where association is taking 835 place 836 RADIO ID = Radio ID where association is taking place 838 5.2.12 CTP_MU-Connect-Rsp 840 This message is sent by the AC to authorize the access point to relay 841 an association response to the MU requesting service. If the 842 association is successful, then the AC MAY also include optional 843 payloads such as Policy which can be enforced at the AP. 845 If the association is rejected by the AC, the AP must disallow 846 association of the MU. 848 HEADER 849 Type = 52 850 SessionID = AP session id from registration 852 PAYLOAD 853 REQ ID = from the corresponding MU-Connect-Req message 854 MU-MAC-Address = MAC Address corresponding to the associating MU 855 STATUS = [Success (1) | Failure internal error (2)| Failure user 856 deny (3)] 858 5.2.13 CTP_MU-Disconnect-Req 860 This message is sent by the AC to request that a specific Mobile Unit 861 session be removed from the AP list of currently connected devices. 862 This operation may be the result of Mobile Unit roaming to a 863 different AP or the result of Mobile Unit session timeout, or 864 administrator request. 866 The MU-MAC-Address identifies the device in question. 868 HEADER 869 Type = 53 870 SessionID = AP session id from registration 872 PAYLOAD 873 REQ ID = ID for the request. Must increment after every 874 retransmission of this message. 875 MU-MAC-Address = MAC Address corresponding to the MU that is to be 876 disconnected. 877 RADIO ID = Radio ID where disconnection is required. 879 5.2.14 CTP_MU-Disconnect-Rsp 881 This message is sent by the AP to indicate that it has successfully 882 processed a disconnect request by the AC. At this point the MU should 883 no longer be associated with the AP. 885 HEADER 886 Type = 54 887 SessionID = AP session id from registration 889 PAYLOAD 890 REQ ID = Same ID that was received in the MU-Disconnect-Req 891 message. 892 MU-MAC-ADDRESS = MAC Address corresponding to the MU that was 893 disconnected 894 STATUS = [Success (1) | Failure (2)] 896 5.2.15 CTP_MU-Disconnect-Nfy 898 This message is sent by the AP to the AC to indicate that it has 899 received an explicit disconnection message from the MU. The 900 transmission of this message from the AP is dependent on the MAC 901 layer of the radio technology implemented on the AP as well as the 902 capability of the MU. For example, the radio MAC layer may or may 903 not support an explicit "disconnect" trigger when an MU goes away. 904 Rather, the disconnection is based on a timer. In cases where the 905 disconnection is timer based, the AC may be the appropriate entity to 906 handle idle timer management. However, in the case where there may 907 be a disconnect indication, then the AP must send this message to the 908 AC when and MU disconnects. 910 HEADER: 911 Type = 57 912 SessionID = AP session ID negotiated at registration 914 PAYLOAD 915 MU-MAC-Address = MAC address of Mobile unit that was disconnected 916 NETWORK ID = 917 RADIO ID = 919 5.2.16 CTP MU-Authenticate-Req 921 This message is sent by the AP to forward an authentication request 922 to the AC. In the case of 802.1x/EAP authentication, the payload of 923 this packet will include information that the AC will forward to a 924 RADIUS Server 926 HEADER 927 Type = 55 928 SessionID = AP session id from registration 930 PAYLOAD 931 REQ ID 932 AUTH_PAYLOAD = The authentication request payload between the AP 933 and the AC carries the request of the MU for authentication. In 934 typical cases this will be the EAP packets from an 802.1x supplicant. 936 5.2.17 CTP MU-Authenticate-Rsp 938 This message is sent by the AC to forward an authentication response 939 to the AP. In the case of 802.1x/EAP authentication, the payload of 940 this packet will include the response from the RADIUS server which 941 will be forwarded to the AP. 943 HEADER 944 Type = 56 945 SessionID � AP session id from registration 947 PAYLOAD 948 REQ ID = from the MU-Authenticate-Req message 949 AUTH_PAYLOAD = The Authentication response payload between the AP 950 and the AC carries the response from the authentication server. In 951 typical cases this will be the EAP packets from the Authentication 952 server. 953 STATUS = [Success (1) | Failure (2)] - Note that the authenticator 954 to authentication server interface resides in the AC so the AC does 955 know the state of the authentication. 956 Note: There may be multiple transitions of this message set. 958 5.3 Configuration and Statistics messages 960 These messages correspond to information and command exchanges 961 between AP and AC only after successful authentication and setup of 962 the secure channel between AP and AC. 964 5.3.1 CTP Cap-Req 966 This message is sent by the AP to indicate to the AC the capabilities 967 of this AP in regards to the number of radios and the types of RF 968 technologies that it supports. The AP will encode its capabilities 969 per each RADIO (or interface) that it supports. These are encoded in 970 a variable length embedded attribute format called �capabilities 971 control frames�. A type-length-value encoding scheme, similar to the 972 format of payloads of regular control messages, is used to encode the 973 capabilities attributes (ATTs) in the capability control frames. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | Value... 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 The available capability attributes are defined as follows: 983 1) ATT-NUM-RADIOS - number of radios that the AP supports. 985 Type= 1 986 Length= 1 byte 987 Value= 1 through 255 989 2) ATT-RADIO-INFO - the information for each radio that 990 consists of the RADIO-INDEX, RADIO-TYPE, and NUM- 991 NETWORKS. There MUST be exactly ATT-NUM-RADIOS number of 992 unique ATT-RADIO-INFO attributes within the Cap-Req 993 message. 995 Type= 2 996 Length= 3 bytes 997 Value= radio information type as defined below: 999 0 1 2 1000 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | RADIO-INDEX | RADIO-TYPE | NUM NETWORKS | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 where 1007 RADIO-INDEX is a unique index of the enumeration of the 1008 number of radios that the AP supports. The AC will use this 1009 value for subsequent configuration and control. 1011 RADIO-TYPE is defined as 1013 o Reserved = 0 1014 o 802.11a = 1 1015 o 802.11b only = 2 1016 o 802.11g only = 3 1017 o 802.11b and g = 4 1018 o 802.11n = 5 1019 o 802.15.1 = 6 1020 o 802.15.3 = 7 1021 o 802.15.4 = 8 1022 o 802.20 = 9 1023 o 802.22 = 10 1024 o Reserved = 11 through 254 1025 o All = 255 (this value indicates that 1026 all interfaces are configurable 1027 to any radio type) 1029 NUM-NETWORKS is the number of unique networks that each 1030 RADIO supports. 1032 3) ATT-MAC-INFO � This attribute consists of information 1033 pertaining to the implementation of the wireless MAC 1034 layer in the WTP. This in turn specifies to the AC the 1035 expected data type that will be received. At this time 1036 only two types of MAC implementation are supported, ie. 1037 Local MAC and Split MAC. 1039 Type= 3 1040 Length= 2 bytes 1041 Value= MAC layer information as defined below: 1043 0 1 1044 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | RADIO-INDEX | MAC-TYPE | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 where 1051 RADIO-INDEX is a unique index of the enumeration of the 1052 number of radios that the AP supports 1054 MAC-TYPE is defined as 1056 o Local MAC = 1 1057 o Split MAC = 2 1059 4) ATT-NETWORK-INFO - This attribute consists of the unique 1060 information that identifies each network per RADIO-INDEX 1061 and consists of RADIO-INDEX, NETWORK-INDEX and NETWORK- 1062 ID. Each Cap-Req payload MUST contain exactly NUM- 1063 NETWORKS worth of unique ATT-NETWORK-INFO attributes. 1065 Type= 4 1066 Length= 8 bytes 1067 Value= network information type as defined below: 1069 0 1 2 3 1070 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 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | RADIO-INDEX | NETWORK-INDEX | NETWORK ID | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | NETWORK ID | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 where 1079 RADIO-INDEX is a unique index of the enumeration of the 1080 number of radios that the AP supports 1082 NETWORK-INDEX is a unique index of the enumeration of the 1083 networks that each RADIO supports 1084 NETWORD-ID is the unique identifier for the network. This 6 1085 byte value MAY be the MAC address for the given network 1086 within the radio. In the case of 802.11 radios, this value 1087 SHOULD be the BSS ID. 1089 5) ATT-VENDOR-ID - name of vendor or manufacturer of AP. 1091 Type= 5 1092 Length= 4 bytes 1093 Value = a 32-bit value containing the IANA assigned 1094 "SMI Network Management Private Enterprise Codes" [3]. 1096 6) ATT-PRODUCT-ID - name of product. 1098 Type= 6 1099 Length= variable length value of string 1100 Value= ASCII string for the name of the product, non- 1101 Null terminated. 1103 HEADER 1104 Type = 20 1105 SessionID = AP session id from registration 1107 PAYLOAD 1108 REQ ID = increments with each retransmission. 1109 The capabilities attributes encoded as TLVs and as defined above. 1111 5.3.2 CTP Cap-Rsp 1113 This message is sent by the AC to acknowledge the capabilities of the 1114 AP. The AC must ack or nak the capabilities for each RADIO-INFO 1115 element that it received in the Cap-Req message. This is 1116 accomplished by sending back exactly ATT-NUM-RADIOS worth of ATT- 1117 RADIO-INFO-ACK for each RADIO-INFO sub-attribute that this AC 1118 supports. 1120 The ATT-RADIO-INFO-ACK is an attribute that contains the RADIO-INDEX 1121 and CAP-STATUS sub-attribute. For each Radio type that the AC 1122 supports, the CAP-STATUS must be set to 1. For each radio type that 1123 the AC does not support, the CAP-STATUS must be set to 0. 1125 Type= 7 1126 Length= 2 bytes 1127 Value= as defined below. 1129 0 1 1130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | RADIO-INDEX | CAP-STATUS | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 HEADER 1136 Type = 21 1137 SessionID = AP session id from registration 1139 PAYLOAD 1140 REQ ID = ID corresponding to the Cap-Req message. 1141 The AC capabilities attribute response encoded as TLVs and as 1142 defined above. 1144 5.3.3 CTP Config-Req 1146 This message is sent by the AP to request configuration from its 1147 master AC. This message must be sent only after a receipt of a 1148 successful Auth-Rsp message from the AC and the verification of the 1149 AC�s AC REG RESPONSE payload. 1151 HEADER 1152 Type = 8 1153 SessionID � the assigned ID as received in the Auth-Rsp message. 1155 PAYLOAD 1156 REQ ID 1157 No specific information is required on this message. 1159 5.3.4 CTP Config-Rsp 1161 This message is sent by the AC as a response to a Config-Req message 1162 to provide the configuration parameters for the registered AP. 1164 HEADER 1165 Type = 9 1166 SessionID = AP session id from registration 1167 Sequence Number = Sequence number of current packet. 1169 PAYLOAD 1170 REQ ID = from Config-Req message 1171 STATUS = [Success (1) | Failure (2)] 1172 CONFIG = The type of the configuration payload is defined in 1173 Section 5.3.10. 1175 5.3.5 CTP Config-Ack 1177 This message is sent by the AP to indicate proper reception of an 1178 AP_Config-Rsp message. This message is particularly important in 1179 processing multi-sequenced packets, in particular configuration 1180 updates that require more than one payload for full receipt of 1181 configuration information. 1183 HEADER 1184 Type = 10 1185 SessionID = AP session id from registration 1187 PAYLOAD 1188 None 1190 5.3.6 CTP_Config-Status-Notify 1192 This message is used by the AP to indicate to the AC that it has 1193 successfully completed it's configuration as per parameters indicated 1194 by the AP. 1196 HEADER 1197 Type = 11 1198 SessionID = AP session id from registration 1200 PAYLOAD 1201 STATUS 1203 5.3.7 CTP_Stats-Notify 1205 This message is sent by the AP to provide periodic operational 1206 statistics to the AC. This message is also used following a correct 1207 configuration establishment to indicate to the AC that the AP is 1208 functionally ready to enter ACTIVE state. 1210 HEADER 1211 Type = 14 1212 SessionID = AP session id from registration 1214 PAYLOAD 1215 STATS - The type of the statistics payload is defined in Section 1216 5.3.10. 1218 5.3.8 CTP Stats-Req 1220 This message is sent by the AC to request statistics information upon 1221 request. It is intended to be used as an interface by an 1222 administrator or management application to query the AP for 1223 instantaneous statistics information. 1225 HEADER 1226 Type = 18 1227 SessionID = AP session id from registration 1229 PAYLOAD 1230 STATS = The type of the statistics payload is defined in Section 1231 5.3.10 1233 5.3.9 CTP Stats-Rsp 1235 This message is sent by the AP to provide operational statistics to 1236 the AC as per the Stats-Req message. It is similar in format to the 1237 Stats-Notify message. 1239 HEADER 1240 Type = 19 1241 SessionID = AP session id from registration 1243 PAYLOAD 1244 STATS = The type of the statistics payload is defined in Section 1245 5.3.10 1247 5.3.10 Configuration and Statistics 1249 Two data representations were considered for the CTP configuration 1250 and statistics payload. The first data representation considered was 1251 a TLV representation where all the variables for the statistics and 1252 configuration would be defined as groups of TLVs. Given the nature of 1253 CTP as a radio agnostic protocol and the complexity of the statistics 1254 and configuration of the 802.11 protocols with multiple networks per 1255 radio a TLV representation might be cumbersome and not extensible. 1257 Most of today�s network devices in both the enterprise and the 1258 carrier space employ the Simple Network Management Protocol. Thus, it 1259 is natural to assume that most, if not all, APs will contain an 1260 embedded SNMP agent able to decode SMI representations. Using SMI 1261 representations for configuration and statistics variables can speed 1262 up deployment of CTP without incurring additional cost for the APs. 1263 Our recommendation is to reuse the 802.11 MIBs where applicable for 1264 the CTP configuration and statistics message payload. MIB extensions 1265 should be defined where the corresponding IEEE MIBs are not 1266 sufficient. Upon reception of the message the CTP daemon should 1267 forward the configuration and statistics message payload to the SNMP 1268 daemon for further decoding and processing of the SMI O.I.D.s. 1270 5.4 CTP_Data Messages 1272 The CTP data messages use the same CTP header as the control and 1273 other messages. If the Type field is 15 (CTP-Data), then the Policy 1274 field of the header is used by the AC to tag the data for special 1275 handling. The interpretation of the Policy field is left up to the 1276 implementation. An example of its use is as follows: 1278 Data packet coming into the AC from the wired network is a voice 1279 packet as indicated by the TOS or DSCP markings in the IP header. 1280 This TOS/DSCP byte will be copied to the outer transport header for 1281 proper priority handling within the network between the AP and the 1282 AC. However, for appropriate classification at the AP, the AC sets 1283 the Policy field to a value that allows the AP to prioritize this 1284 packet over other data packets that may have a lower priority. 1285 Similarly in the reverse direction, the MU may have set the 1286 appropriate fields in the original IP header, but the AP can 1287 interpret those bits and map them to the Policy field in the CTP-Data 1288 header for special dispensation at the AC. 1290 5.4.1 CTP_Data 1292 This message is utilized as the transport of MU layer data. The 1293 contents of the message body are not interpreted by the AP layer 1294 other than sending it to the MAC layer of the AP. 1296 HEADER 1297 Type = 15 1298 SessionID = AP session id from registration 1299 Policy = as set by the implementation 1301 PAYLOAD 1302 802.3 frame 1304 6. State Machines 1306 This state machine in Figure 4 indicates the logical state 1307 transitions of the CTP session establishment. 1309 user-request/reset 1310 +----------------------------------------------+ 1311 | | 1312 | | 1313 | | 1314 | | 1315 | | 1316 V +-----------+ | 1317 +------+ Success | Control | Success +----------+ 1318 | Init |------------->| Session |--------->| Active | 1319 +------+ | Establish | +----------+ 1320 ^ +-----------+ ^ | 1321 | | | | 1322 | | | | 1323 | | user-req | |user-req 1324 | | | | 1325 | | | | 1326 | Failure | | V 1327 +--------------------------+ +----------+ 1328 | Standby | 1329 +----------+ 1331 Figure 4 - Simple CTP state machine 1333 6.1 Init 1335 This state represents the boot state, and initialization of the 1336 hardware. Entry into this state is either Failure of the Control 1337 Session Establishment or user-request or reset signal from the Active 1338 state 1340 6.2 Control Channel Establishment 1342 Once Initialization completes the AP initiates the control channel 1343 establishment phase of the connection. Any phase within this state 1344 that fails because of a STATUS=FAILURE or no response from either 1345 device will result in a failure of the whole phase and go back to 1346 initialization. A successful completion of the control session 1347 establishment process will include 1348 Registration 1349 Authentication 1350 Software Upgrade Notification 1351 Capability negotiation 1352 Configuration Request 1353 Configuration Response 1354 Configuration Ack. 1356 Upon receipt of a successful Config-Ack from the AP, the AP and AC 1357 session for the AP are put into ACTIVE state. 1359 6.3 Active State 1361 Once confirmation of successful registration is received the device 1362 now has a properly established communications/tunneling session with 1363 the AC. The Authentication response MUST have indicated a valid CTP 1364 session ID by which this tunnel is registered on the AC. So in this 1365 state, the SessionId MUST be non-zero. 1367 This state persists until device terminates or communications with 1368 the AC are interrupted. To assist in the detection of connection 1369 termination, the device MUST implement the CTP Poll-Req and Poll-Rsp 1370 messages as described previously. Another method of exiting this 1371 state is with an explicit Set-State message that may only be 1372 initiated by the AC to the AP. 1374 6.4 Standby State 1376 At some time during the operation, it may be necessary to instruct an 1377 AP to halt its current operation, ie. to switch off the RF 1378 interface(s) on the AP . This is done by the Set-State message. The 1379 device will remain in this state, until explicitly told by the AC to 1380 resume operation also using the Set-State message. 1382 7. Authentication, Encryption and Session Key generation 1384 Since the AP and AC can be separated over any arbitrary L3 cloud, 1385 first and foremost there is a need for a secure binding between the 1386 AC and AP. A control channel security association is required 1387 between the AC and AP. 1389 7.1 Authentication 1391 The AC and AP must go through a mutual authentication phase during a 1392 registration and authentication process and form a security 1393 association. A couple of assumptions are made to ensure this 1394 security association is created. First, there must be a secure 1395 mechanism to get the digital certificates onto the APs and ACs and 1396 that process must be run either at the factory or prior to device 1397 deployment. Secondly, the placement of the AP ID (in most cases the 1398 AP serial number) in a data store on the AC assumes a secure 1399 insertion mechanism. This may be a manual process or other secure ID 1400 provisioning methods may be employed. Mutual authentication of AP and 1401 AC is done by means of digital certificates as is described below. 1403 +----+ +----+ 1404 | AP | | AC | 1405 +----+ +----+ 1406 Reg-Req(AP-ID) 1407 ----------------------------------------------> 1409 Reg-Rsp(Status,AP-challenge) 1410 <---------------------------------------------- 1412 Auth-Req(AP-ID,AP-cert,AP-resp,AC-challenge) 1413 -----------------------------------------------> 1415 Auth-Rsp(Status,AC-cert,AC-rsp,Session-Key) 1416 <----------------------------------------------- 1418 AP-ID - AP SERIAL NUMBER attribute. This attribute is assumed to be 1419 available in a data store in the AC as well as being factory burnt-in 1420 in the AP device. The AC will respond with a STATUS=Success in the 1421 Reg-Rsp message if there is a match in its data store for the given 1422 AP-ID 1424 AP-challenge - is a 16 byte random number generated using [4] as 1425 guidelines for the randomness of the challenge. 1427 AP-cert - Is a digital certificate assumed to be available on the AP 1428 prior to its Registration request. The mechanism to get the 1429 certificate onto the AP is out of scope for this document. 1431 AP-resp - Is a digital signature over the SHA-1 hash of the AP- 1432 challenge concatenated with the AP-ID. 1433 S-ap(H-sha1(AP-challenge|AP-ID)) 1435 AP-challenge - is a 16 byte random number generated for subsequent 1436 authentication of the AC. 1438 AC-cert - Is a digital certificate or chain of certificates of the AC 1439 that is assumed to be available on the AC prior to sending the Reg- 1440 Rsp message. The mechanism to get the certificate or chain of 1441 certificates onto the AC is out of scope for this document. 1443 AC-resp - is a digital signature over the SHA-1 hash of the AC- 1444 challenge concatenated with the encrypted session key. 1445 S-ac(H-sha1(AC-challenge|Enc-ac-p(SessionKey))) 1447 Session Key - is actually the encrypted randomly generated session 1448 encryption keying material. The AC uses the public key of the AP to 1449 encrypt the session encryption key. The size of the Session Key is 19 1450 bytes. The first 16 bytes are used as AES-CCM encryption and the 1451 remaining 3 bytes are used as a salt for a nonce which is required by 1452 the AES-CCM algorithm. See section 7.2 for encryption details. 1453 The Session key is a random number generated using [4]. At the time 1454 of writing this document there are no known weak keys for AES. 1456 The following steps describe in detail the registration and 1457 authentication process: 1459 1. The AP sends a Reg-Req message with its AP SERIAL NUMBER. If it 1460 does not receive a Reg-Req within 3 seconds, it must resend the 1461 Reg-Req message. 1462 2. Upon receipt of the Reg-Req message, the AC checks its data store 1463 for the AP SERIAL NUMBER. If it exists then the AC sends back a 1464 Reg-Rsp message with STATUS payload with Success (1) attribute 1465 and an AP CHALLENGE payload. If the AP SERIAL NUMBER does not 1466 exist, then a Reg-Rsp message with a STATUS payload of Failure 1467 (2) is sent back. 1468 3. The AP will take the AP CHALLENGE payload, concatenate it with 1469 the AP SERIAL NUMBER and calculate an AP RESPONSE as shown above 1470 and send it back to the AC along with an AC CHALLENGE payload and 1471 its own digital CERTIFICATE payload in an Auth-Req message. 1472 4. Upon receipt of the Auth-Req message the AC will 1473 a. Verify the AP's digital certificate 1474 b. Verify the AP RESPONSE, which was the digital signature of 1475 the AP over the hash of the AP CHALLENGE and the AP SERIAL 1476 NUMBER. This is done with the public key of the AP. 1477 c. If both a) and b) are verified correctly, then the STATUS 1478 payload will contain Success (1). Otherwise it will contain 1479 Failure (2). 1480 d. If Success, then the AC will add its own CERTIFICATE to the 1481 Auth-Rsp message 1482 e. Encrypt the session encryption keys with the public key of 1483 the AP. 1484 f. Generate a unique SessionID to be used in subsequent CTP 1485 messages. 1486 g. Send back an Auth-Rsp message with STATUS, CERTIFICATE, AC 1487 RESPONSE and SESSION KEY payloads with the SessionID in the 1488 CTP header. 1489 5. Upon receipt of the Auth-Rsp message, the AP will 1490 a. Verify the AC's digital certificate 1491 b. Verify the AC RESPONSE which was the digital signature of the 1492 AC over the hash of the AC CHALLENGE and the encrypted 1493 session encryption key. 1494 c. Decrypt the encrypted session encryption key with its own 1495 private key 1497 d. Store the SessionID which will be used in each subsequent CTP 1498 message. 1499 6. All CTP control messages after the Auth-Rsp will be sent 1500 encrypted with AES-CCM as described in section 7.2. 1502 7.2 Encryption 1504 Once the registration and authentication process has successfully 1505 completed then the control traffic is encrypted. The traffic is 1506 confined to control, configuration and management traffic between the 1507 AC and AP. 1509 It is believed that for security sensitive applications and 1510 deployments there will always be an end to end encrypted tunnel for 1511 MU data traffic. Therefore, a data path encryption mechanism is not 1512 provided by CTP. 1514 All control messages except of CTP_Reg-Req, CTP_Reg-Rsp, CTP_Auth-Req 1515 and CTP_Auth-Rsp, which are used to establish a trust relationship 1516 between the AP and AC, must be encrypted. If a non-encrypted CTP 1517 control packet with type other than CTP_Reg-Req, CTP_Reg-Rsp, 1518 CTP_Auth-Req and CTP_Auth-Rsp is received, it MUST be dropped by a 1519 receiver and no notification is sent to the sender. 1521 Encrypted packets MUST be sent in the following format: 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Ver |0|0|0|P|E| Type | Policy | Reserved | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Session Id. | Length | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | IV (8 bytes) | 1531 | | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Sequence Number | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Encrypted data | 1536 | (var length) | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Authentication Data (variable) | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 The first 8 bytes is general CTP header described in section 4.1. E 1542 bit MUST be equal to 1. 1544 The additional fields have the following meaning: 1546 IV � Initialization Vector used by AES-CCM as described in section 1547 7.2. 1549 Sequence Number � 32 bits value used for anti-replay protection. 1551 Encrypted Data � data of variable length encrypted with AES-CCM. 1552 Typically the encrypted data corresponds to the specified message 1553 payloads. 1555 Authentication Data � MAC of CTP header, IV, Sequence Number and 1556 encrypted data. 1558 CTP uses AES-CCM encryption as defined in [5] with value L = 4 and 1559 value M = 8. The Nonce length is 11 bytes. The Nonce is formed by 1560 concatenation of 3 bytes of the salt send by AC to the AP during 1561 Session Key exchange and 8 bytes of Initialization Vector. The sender 1562 of a packets MUST NOT send two packets with the same IV, as it 1563 immediately leads to plain-text revealing. 1565 The Sequence Number field MUST start from zero for the first 1566 encrypted packet and is incremented each time a packet is encrypted. 1567 The receiver MUST use the sequence number field to protect against 1568 replay-attack and MAY use it to accept reordered or late packets. The 1569 sender MUST negotiate a new session key before reaching maximum value 1570 for the Sequence Number. 1572 The sender of an encrypted packet MUST perform the following steps 1573 during the packet encryption: 1574 - IV and the Sequence Number are inserted into the packet after CTP 1575 header. 1576 - E bit in CTP header is set to 1. 1577 - The first 20 bytes including CTP header, IV and the Sequence 1578 Number are passed to AES-CCM for authentication only. 1579 - The CTP payload is encrypted with AES-CCM. 1580 - After encryption, a MAC value received from AES-CCM is copied to 1581 the output packet after encrypted data. 1582 - The Sequence Number MUST be incremented 1583 - IV value must be changed to another value which has not been used 1584 so far with the current encryption key. 1586 The receiver of the encrypted packet MUST perform the following steps 1587 during the packet decryption: 1588 - E bit in CTP header is checked. If it is not 1, the packet is 1589 silently dropped. 1590 - Type of the packet is checked. All control packets except CTP_Reg- 1591 Req, CTP_Reg-Rsp, CTP_Auth-Req and CTP_Auth-Rsp must be encrypted. 1592 - The Sequence Number is compared to the sequence number of the last 1593 received packet, which MUST be stored by the receiver. If the 1594 Sequence Number is larger that the one stored by the receiver the 1595 packet MUST be accepted for further processing. If the sequence 1596 number is equal to the one stored by the receiver the packet MUST 1597 be silently dropped. If the sequence number is lower that stored by 1598 the receiver, packet MAY be accepted it the receiver implements 1599 sliding window algorithm. 1600 - Payload of the packet is passed for decryption to AES-CCM 1601 algorithm. 1602 - The first 20 bytes of the packet starting with CTP header are 1603 passed to AES-CCM for authentication. 1604 - Data payload is passed to AES-CCM for decryption 1605 - After decryption, MAC value received from AES-CCM decryption 1606 process is compared to the MAC value received in the packet. If 1607 locally calculated MAC does not match the MAC value from the 1608 received packet, the packet MUST be silently dropped. If MAC values 1609 are equal, the packet is passed for further processing. 1610 - IV, the Sequence Number and MAC values are stripped from the 1611 packet. 1612 - If the Sequence Number from the received packet is larger than 1613 stored by the receiver, the receiver must update the stored 1614 sequence number with the received one. 1616 7.3 Session Key refresh and generation 1618 One session key is used to encrypt control packets exchanged in both 1619 directions between the AP and the AC. The Session Key is always 1620 generated by the AC and is sent to AP during the CTP registration and 1621 authentication phase as described in section 7.1. 1622 The Session Key must be refreshed before either one of the following 1623 happens: 1624 - key lifetime expires 1625 - sequence numbers are exhausted 1627 The Session Key�s lifetime is not negotiated in-band and is set to 24 1628 hours. 1630 If the Session Key�s lifetime has expired or the sequence numbers has 1631 been exhausted and the new Session Key has not been negotiated, the 1632 receiver MUST silently drop any received packet and the sender MUST 1633 NOT encrypt CTP packet. 1635 The Key refresh is always initiated by the AP. The packet exchange 1636 between the AP and the AC for new key is TBD. 1638 The AC MAY request the AP to start the key refresh process by sending 1639 TBD packet. 1641 After the Session Key refresh, the AC must use the old key until it 1642 receives a packet encrypted with the new Session Key, what is an 1643 indication that the AP received and accepted the new Session Key. 1645 8. Security considerations 1647 CTP provides mutual authentication of the AP and the AC. The trust is 1648 achieved by digital certificates. The trust hierarchy leading to 1649 successful certificate or certificates chain validation is out of 1650 scope of this document. 1652 Certificates issued for the AP and the AC are bound to the serial 1653 number of the AP and the AC respectively. 1655 During the authentication exchange, the receiver cannot verify that 1656 the sender of the certificate really has the serial number presented 1657 in the certificate. An attacker may steal the legitimate credentials 1658 and send a valid certificate from a device with different serial 1659 number. 1661 During the authentication phase the receiver MAY verify whether the 1662 presented certificate has not been revoked. The mechanism of 1663 accessing CRL is not defined by CTP. 1665 CTP encryption and authentication is sufficient for control packets 1666 only. It MUST NOT be used for data encryption, because the exchange 1667 between the AP and the AC does not use ephemeral keys. Compromise of 1668 AP�s private key enables an attacker to decrypt all session keys used 1669 in the past between the AP and AC and decrypt all data packets 1670 exchanged between AP and AC. 1672 Control packets exchanged between the AP and the AC are encrypted and 1673 authenticated. Both, confidentiality and authentication is provided 1674 by AES-CCM as described in [5]. 1676 9. References 1678 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1679 Levels", BCP 14, RFC 2119, March 1997 1681 [2] O�Hara, B., et. al, �CAPWAP Problem Statement�, RFC 3990, 1682 February 2005 1684 [3] "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", 1685 January 2002, ftp://ftp.isi.edu/in-notes/rfc3232 1687 [4] Eastlake, D., et. al., "Randomness Recommendations for Security", 1688 December 1994, RFC 1750 1690 [5] Whiting, et al., "Counter with CBC-MAC (CCM)", September 2003, 1691 RFC 3610 1693 10. Author's Addresses 1695 Paulo Francisco 1696 Chantry Networks 1697 1900 Minnesota Court 1698 Mississauga, ON M8V 1E5 1699 Canada 1701 Phone: +1 905-363-6410 1702 Email: paulo@chantrynetworks.com 1704 Inderpreet Singh 1705 Chantry Networks 1706 1900 Minnesota Court 1707 Mississauga, ON M8V 1E5 1708 Canada 1710 Phone: +1 905-363-6412 1711 Email: isingh@chantrynetworks.com 1713 Krzysztof Pakulski 1714 Chantry Networks 1715 1900 Minnesota Court 1716 Mississauga, ON M8V 1E5 1717 Canada 1719 Phone: +1 905-363-6400 (ext. 6449) 1720 Email: kpakulski@chantrynetworks.com 1722 Floyd Backes 1723 AutoCell Laboratories 1724 125 Nagog Park 1725 Acton, MA 01720 1726 USA 1728 Phone: +1 978-264-4884 1729 Email: fbackes@autocell.com 1731 Intellectual Property Statement 1733 The IETF takes no position regarding the validity or scope of any 1734 intellectual property or other rights that might be claimed to 1735 pertain to the implementation or use of the technology described in 1736 this document or the extent to which any license under such rights 1737 might or might not be available; neither does it represent that it 1738 has made any effort to identify any such rights. Information on the 1739 IETF's procedures with respect to rights in standards-track and 1740 standards-related documentation can be found in BCP-11. Copies of 1741 claims of rights made available for publication and any assurances of 1742 licenses to be made available, or the result of an attempt made to 1743 obtain a general license or permission for the use of such 1744 proprietary rights by implementers or users of this specification can 1745 be obtained from the IETF Secretariat. 1747 The IETF invites any interested party to bring to its attention any 1748 copyrights, patents or patent applications, or other proprietary 1749 rights which may cover technology that may be required to practice 1750 this standard. Please address the information to the IETF Executive 1751 Director. 1753 Disclaimer of Validity 1755 This document and the information contained herein are provided on an 1756 �AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1758 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1759 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1760 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1763 Copyright Statement 1765 Copyright (C) The Internet Society (2005). This document is subject 1766 to the rights, licenses and restrictions contained in BCP 78, and 1767 except as set forth therein, the authors retain all their rights. 1769 Acknowledgment 1771 Funding for the RFC Editor function is currently provided by the 1772 Internet Society.