idnits 2.17.1 draft-singh-capwap-ctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (May 2004) is 7283 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 285 -- Looks like a reference, but probably isn't: 'SNMP' on line 543 -- Possible downref: Non-RFC (?) normative reference: 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: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations Group 2 Internet Draft I. Singh 3 Document: draft-singh-capwap-ctp-00.txt P. Francisco 4 Chantry Networks 5 F. Backes 6 Propagate Networks 7 Expires: November 2004 May 2004 9 CAPWAP Tunneling Protocol (CTP) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 13, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 With the overwhelming choice of proprietary implementations of 41 centralized control and management of wireless access points and 42 access controllers there is a great demand for a standard protocol 43 and architecture that enables the deployment of large scale wireless 44 networks. 46 This document describes the CAPWAP Tunneling Protocol, a protocol 47 that allows for the centralized control and provisioning of a large 48 number of wireless access points from access controllers. It is 49 supported by an architecture where the MAC layer of the RF technology 50 is terminated within the AP. This allows for the protocol to be 51 extensible to multiple radio technologies. It assumes an IP 52 connection between the access points and access controllers and has 53 signaling primitives to enable wireless station mobility between 54 access points. Therefore, seamless Layer 3 subnet mobility is 55 enabled by this protocol. 57 Table of Contents 59 1. Definitions....................................................4 60 1.1 Conventions used in this document..........................4 61 1.2 Terminology................................................4 62 2. Introduction...................................................4 63 2.1 Out of scope...............................................6 64 2.1.1 Secure discovery of AP and AC.........................6 65 2.1.2 AP image management...................................6 66 2.1.3 Multiple AC mobility..................................7 67 3. Protocol Overview..............................................7 68 3.1 Control and Status Messages................................7 69 3.2 Configuration and Statistics messages......................7 70 3.3 Data Messages..............................................8 71 4. CTP Packets....................................................8 72 4.1 CTP Header format..........................................8 73 4.2 Messages...................................................9 74 4.3 Message Payloads..........................................10 75 5. Message descriptions..........................................13 76 5.1 Message State Control.....................................13 77 5.2 Control and Status messages...............................13 78 5.2.1 CTP Reg-Req..........................................13 79 5.2.2 CTP Reg-Rsp..........................................13 80 5.2.3 CTP Auth-Req.........................................14 81 5.2.4 CTP Auth-Rsp.........................................14 82 5.2.5 CTP SW-Update-Req....................................15 83 5.2.6 CTP SW-Update-Rsp....................................15 84 5.2.7 CTP Set-State-Req....................................16 85 5.2.8 CTP Set-State-Rsp....................................17 86 5.2.9 CTP Poll-Req.........................................17 87 5.2.10 CTP Poll-Rsp........................................17 88 5.2.11 CTP MU-Connect-Req..................................18 89 5.2.12 CTP MU-Connect-Rsp..................................18 90 5.2.13 CTP MU-Disconnect-Req...............................18 91 5.2.14 CTP MU-Disconnect-Rsp...............................19 92 5.2.15 CTP MU-Disconnect-Nfy...............................19 93 5.2.16 CTP MU-Authenticate-Req.............................20 94 5.2.17 CTP MU-Authenticate-Rsp.............................20 95 5.3 Configuration and Statistics messages.....................21 96 5.3.1 CTP Cap-Req..........................................21 97 5.3.2 CTP Cap-Rsp..........................................23 98 5.3.3 CTP Config-Req.......................................24 99 5.3.4 CTP Config-Rsp.......................................24 100 5.3.5 CTP Config-Ack.......................................24 101 5.3.6 CTP Config-Status-Notify.............................25 102 5.3.7 CTP Stats-Notify.....................................25 103 5.3.8 CTP Stats-Req........................................25 104 5.3.9 CTP Stats-Rsp........................................26 105 5.3.10 Configuration and Statistics........................26 106 5.4 CTP Data Messages.........................................26 107 5.4.1 CTP Data.............................................27 108 6. State Machines................................................28 109 6.1 Init......................................................28 110 6.2 Control Channel Establishment.............................28 111 6.3 Active State..............................................29 112 6.4 Standby State.............................................29 113 7. Security Considerations.......................................29 114 8. References....................................................30 115 9. Author's Addresses............................................30 116 10. Appendix I - Registration and Authentication.................31 117 Intellectual Property Statement..................................33 119 1. Definitions 121 1.1 Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119 [1]. 127 1.2 Terminology 129 AP - Access Point - The network device that includes both the 130 wireless termination point as well as the implementation of a 131 specific radio technology management layer. 133 AC - Access Controller - A centralized network entity that controls, 134 configures and manages one or more than one APs. 136 MU - Mobile Unit - A wireless device which is also an IP node capable 137 of dynamic change in its association with an Access Point. 139 2. Introduction 141 The rapid pace with which wireless networks are being deployed in the 142 home, enterprise and carrier industries has led to the proliferation 143 of proprietary solutions which attempt to address problems associated 144 with large scale wireless installations. The main issues plaguing 145 802.11 wireless networks, for example, are described in [2] and can 146 be summarized as: the manageability of large numbers of APs (Access 147 Points); the secure and bulk provisioning, monitoring, and control of 148 APs; and policy control and enforcement of MU (Mobile Units) data 149 flows and policies. 151 One of the key problems with deploying large scale wireless networks 152 is that the infrastructure needs to scale to meet both geographic 153 coverage as well as client density requirements. CAPWAP Tunneling 154 Protocol (CTP) addresses these challenges by minimizing configuration 155 of the wired infrastructure to accommodate the wireless network. 157 CTP provides both centralized configuration and operational control 158 for wireless networks, and in doing so, provides centralized security 159 and policy management. 161 This solution has been currently focused towards 802.11 networks. 162 However, CTP is independent of the layer 2 wireless standard because 163 it assumes that the MAC layer of the wireless technology is fully 164 implemented in the AP. The control channel binding between the AP and 165 AC provides for all the necessary signaling to facilitate MU 166 connection, mobility, and even RF resource management. Thus, it is 167 possible to use CTP to offer IP network services to wireless users 168 independent of the underlying wireless technology (e.g. 802.11, 169 802.15, or 802.16). 171 CTP involves one or more Access Points (APs) connected to one or more 172 Access Controllers (ACs). The network connectivity between the APs 173 and ACs is primarily through a Layer 3 routed network. However, 174 switched Layer 2 or directly connected network topologies are also 175 supported. Figure 1 shows the typical network topology of AP and AC 176 placement in a CTP network. However, since it is assumed that the AP 177 and AC are IP addressable direct connect or L2 connect is also 178 supported. 180 +-------+-------+ 181 | AC | 182 +-------+-------+ 183 | 184 --------+------ LAN 185 | 186 +-------+-------+ 187 | | 188 +-------+-------+ 189 | 190 -----+--+--+--- LAN 191 | | 192 +---+ +---+ 193 | | 194 +--+--+ +--+--+ 195 | AP | | AP | 196 +--+--+ +--+--+ 198 Figure 1 - Topology of AP and AC placement 200 CTP interacts directly with the MAC management entity to monitor and 201 control configuration and wireless connections. CTP tunnels data 202 traffic as 802.3 traffic to the AP and uses the L2 Bridge to pass 203 data to the MAC. Optionally, data traffic can be passed directly to 204 the AP, independent of a CTP data connection. This mode of operation 205 is fully controlled by the AC rather than being an inherent property 206 of the AP. There has been wide interest in this deployment model in 207 the case where the link between the AC and the AP is a slow WAN link, 208 for example. By bridging the MU data traffic locally at the AP's 209 network, and still controlling the authentication centrally via the 210 AC, the user is able to forgo the possibility of the data traffic 211 having to traverse the slow WAN link upstream and then again 212 downstream to access, for example, a local printer. In this 213 centralized architecture solution of CTP, the layer 2 wireless 214 termination point and the MAC layer are fully implemented in the AP 215 as shown in Figure 2, which enables this type of feature. 217 +--+--+ +----+------+ 218 Control <===>| | (Control) | | 219 | CTP |<===========>|WirelessMAC| 220 Data <--->| | | | 221 +--+--+ +----+------+ 222 ^ ^ 223 | +-----------+ | 224 | | | | 225 Data (optional) <-------+--->| L2 bridge |<---+ 226 | (Data) | 227 +-----------+ 229 Figure 2 - CTP and MAC interaction in an AP 231 2.1 Out of scope 233 The following areas are out of scope for this version of the 234 protocol. 236 2.1.1 Secure discovery of AP and AC. 238 Rather than specify a brand new secure discovery mechanism for APs 239 and ACs within this protocol, CTP specifies the context and security 240 credentials that are required to register APs into ACs. All AP 241 implementations of CTP MUST provide a method to statically configure 242 the IP address(es) of the AC to be stored in the non-volatile RAM of 243 the AP. 245 Other methods for automatic discovery that MAY be used by 246 implementations of CTP are: SLP, DNS name resolution, and DHCP 247 options for AC IP address(es). The mechanism by which these methods 248 are incorporated into CTP is out of scope for this document but is a 249 worthwhile task for the working group that takes on this work. 251 2.1.2 AP image management. 253 A conscious decision in the design of this protocol excluded the 254 implementation of an AP image management system. However, CTP 255 provides triggers for software upgrade, ie. a message to indicate 256 software version and a message to command the AP to initiate software 257 upgrade. The actual protocol and mechanism for secure software 258 download has been deemed out of scope for the protocol and beyond 259 what the protocol was intended for. 261 2.1.3 Multiple AC mobility 263 This version of CTP does not include the details of support for 264 multi-AC control over APs for the purposes of multi-AC MU mobility. 265 However, the reserved message types and the capability exchange phase 266 may be used to facilitate the setting up of intra-AC tunnels. 268 3. Protocol Overview 270 CTP is a generic protocol that defines a mechanism for the control 271 and provisioning of wireless APs through centralized ACs. In 272 addition, it provides a mechanism to optionally tunnel the mobile 273 client data between the AP and AC. 275 There are two types of CTP packet headers: 277 a) Control: these messages allow the AC to provision and control 278 the APs and MU session state and further contain messages that 279 consist of configuration, statistics and state management. 281 b) Data: an optional aspect of the protocol that allows MU data 282 packets tunneled between the AP and the AC. 284 The CTP messages between APs and ACs are delivered by a UDP transport 285 and the UDP port number is [TBD]. The message types of this protocol 286 are classified into three distinct categories: 288 o Control and Status messages 289 o Configuration and Statistics messages 290 o Data messages. 292 3.1 Control and Status Messages 294 The set of control messages of CTP provides a mechanism for an AP to 295 register itself with the AC and to interact with the MU session 296 management operations of the AC. Primarily this set is utilized by 297 the AP to request session association with the AC, configuration 298 information, and to provide the mechanism and notification of MU 299 connection to the AC. The AC uses this message set to acknowledge AP 300 and MU session establishment and to explicitly control both AP and MU 301 session operational state (such as AP state changes, AP and MU 302 session disconnection, etc.) 304 3.2 Configuration and Statistics messages 306 This logical set of messages exchanged between AP and AC is primarily 307 intended for the provisioning of the AP via a capabilities exchange 308 and configuration message set. This message set also includes a 309 means for the AP to provide periodic status notifications of current 310 operational state, statistics information such as wireless and wired 311 statistics, security alerts, etc. 313 3.3 Data Messages 315 The CTP-Data message is the only message in this set. Its purpose is 316 to carry encapsulated frames associated with a registered MU. This 317 message type utilizes the Policy field of the message header to 318 provide user based, post authentication policy enforcement on a per 319 packet basis. This message type applies to actual MU client data and 320 does not include MU association, authentication and MU session 321 management messages as those operations are explicitly represented 322 though specific control messages. 324 It must be noted that the protocol allows for the data path to not 325 have to traverse the AC. In that case, no policy can be applied on a 326 per user basis centrally. 328 4. CTP Packets 330 It is assumed that the AP and AC source and destination information 331 is available in the transport layer headers. As such, it is not 332 indicated below. 334 4.1 CTP Header format 336 Figure 3 describes the CTP message header format: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Ver |0|0|0|0|E| Type | Policy | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Session Id. | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Message Payload... 346 +-+-+-+-+ 348 Figure 3 - CTP Header format 350 Ver Field 352 This field identifies the version of the protocol. It is 3 bits of 353 data. For this specification the version field is 0. 355 Flags Field 356 This field is a bitmask of 5 bits that represents special CTP 357 processing. Bits 3, 4, 5 and 6 are undefined and MUST be zero (0). 358 Bit #7 as follows: 360 Bit E - Data path Encryption 361 1 indicates that the CTP-Data message type data is encrypted 362 0 indicates that the CTP-Data message is in the clear 364 Type Field 366 This is a 1 byte field that identifies the message type. The message 367 types are identified in Section 4.2. 369 Policy Field 371 This is a 1 byte field that represents policy to be assigned and 372 enforced. The definition of this policy field is dependent on the 373 message type. For example, if the message type is CTP-Data (defined 374 below) the Policy field corresponds to QOS policy for the MU data 375 above and beyond the QOS TOS markings or DiffServ markings that may 376 have been applied to the end-to-end user data. If the message type 377 is not CTP-Data, then this field is not interpreted by either AP or 378 AC and MUST be set to all zeros. 380 Reserved 382 Reserved for future use. MUST be set to zero (0). 384 Session ID Field 386 This is a 2 byte field that includes a unique session identifier 387 provisioned by the AC after successful authentication. 389 Length Field 391 This is a 2 byte field that indicates the length of payload (excludes 392 the header length). 394 4.2 Messages 396 The following message types are defined in CTP: 397 Message Type 398 ----------------------------- 400 Reserved 0-1 401 Reg-Req 2 402 Reg-Rsp 3 403 Auth-Req 4 404 Auth-Rsp 5 405 SW-Update-Req 6 406 SW-Update-Rsp 7 407 Config-Req 8 408 Config-Rsp 9 409 Config-Ack 10 410 Conf-Status-Notify 11 411 Set-State-Req 12 412 Set-State-Rsp 13 413 Stats-Notify 14 414 CTP-Data 15 415 Poll-Req 16 416 Poll-Rsp 17 417 Stats-Req 18 418 Stats-Rsp 19 419 Cap-Req 20 420 Cap-Rsp 21 421 Reserved 22-50 422 MU-Connect-Req 51 423 MU-Connect-Rsp 52 424 MU-Disconnect-Req 53 425 MU-Disconnect-Rsp 54 426 MU-Authenticate-Req 55 427 MU-Authenticate-Rsp 56 428 MU-Disconnect-Nfy 57 429 Reserved 58-255 431 4.3 Message Payloads 433 Each message type defined above may or may not have a corresponding 434 CTP message payload. The payload contents are exchanged with the AC 435 through the exchange of relevant Type-Length-Value (TLV) elements. 437 Each element is encoded as follows: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Value... 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Type 449 One of the element types as defined below 451 Length 452 Total length of the value field 454 Value 455 Value 457 Several elements may be combined in sequence to provide a full 458 payload definition. 460 Note: In order to properly utilize TLVs, the length field of the CTP 461 header must be properly calculated and includes the sum of the length 462 fields of all TLVs in the payload. 464 The following provides a list of TLVs as defined in this version of 465 the protocol: 467 Definition Type Length Description 468 (bytes) 469 --------------------------------------------------------------------- 471 STATUS 1 1 Explicit indication of the 472 response to requests messages. 473 Values for STATUS are the same 474 across all messages: 475 0 - Undefined 476 1 - Success 477 2 � Failure 479 SWVersion 2 Variable ASCII text representation of 480 the AP software version 481 number. 483 AP SERIAL_NUMBER 3 Variable Unique ASCII representation of 484 the Serial number of AP. This 485 serial number of the AP must 486 be a priori available to the 487 AC. Method of getting this 488 serial number to the AC is out 489 of scope for this document. 491 AP REG_CHALLENGE 4 16 A 16 byte random challenge 492 generated by the AC, to be 493 used by AP upon registration. 495 AP REG_RESPONSE 5 16 A 16 byte AP calculated 496 response to AP REG CHALLENGE 498 AC REG CHALLENGE 6 16 A 16 byte random challenge 499 generated by the AP, to be 500 used by AC upon registration 501 request. 503 AC REG_RESPONSE 7 16 A 16 byte AC calculated 504 response to AC REG CHALLENGE 506 AC_IPADDR LIST 8 Variable List of AC IP addresses with 507 which said AP should attempt 508 to connect 510 NETWORK ID 9 4 Network ID with which a given 511 radio in the AP is associated. 512 This value is unique as it is 513 calculated by the AC upon the 514 provisioning phase of the AP 515 and provided to it in the 516 Config-Rsp message. In the 517 case of 802.11 radio 518 technology, this is the 519 Extended Service Set (ESS) to 520 which the AP belongs. This is 521 a 32 bit integer represent- 522 ation of the ESS. For other 523 radio technologies, this is a 524 unique value representing the 525 network that the radio is a 526 member of. 528 CONFIG 10 variable Value contains a 529 [SNMP] set OIDs of encoded 530 configuration elements 532 AP_STATE 11 1 Value contains indication of 533 AP state: 534 0=Standby 535 1=Active 536 2=Reset 538 SESSION_KEY 12 16 Encrypted session encryption 539 key to secure AP to/from AC 540 communications. 542 STATS 13 Variable Value contains a 543 [SNMP] set of OIDs of encoded 544 statistics elements 546 CERTIFICATE 14 Variable Digital certificate 547 credentials of the AP or AC 549 RADIO ID 15 1 Index number of the radio as 550 learnt during the Capabilities 551 exchange. 553 REQ ID 16 1 Message identification to 554 match request and response 555 messages. 557 5. Message descriptions 559 5.1 Message State Control 561 Unless otherwise stated, every message that is a "request" type 562 includes a REQ ID payload inserted by the sender of the message. 563 This is sent so as to aid in the match of messages that are received 564 as "responses". After the transmission of each request, the source 565 will wait up to 2 seconds for the reception of the response. If a 566 response is not received, the source will retransmit the packet up to 567 3 times. If after 3 attempts a response is still not received the 568 source aborts the session and resets its state machine. If the 569 source is the AP, the AP shall resume registration operations. 570 Correspondingly the AC will simply delete the AP session from its 571 database and drop all packets which are from unregistered APs. 573 5.2 Control and Status messages 575 5.2.1 CTP Reg-Req 577 This message is used by the AP to request registration with the AC. 579 This message is initiated by the AP after successful secure discovery 580 and following the hardware and software initialization sequence of 581 the AP. The Session ID of this message is set to 0x0000 because the 582 AC will subsequently assign a Session ID upon successful 583 authentication. This message requires a mandatory payload, namely 584 "AP Serial Number". 586 HEADER 587 Type = 2 588 SessionID = 0x0000 590 PAYLOAD 591 REQ ID 592 AP SERIAL NUMBER 594 5.2.2 CTP Reg-Rsp 596 This message is sent by the AC to an AP to indicate that it has 597 conditionally accepted the AP's registration request based on knowing 599 who the AP is and based on the provided serial number. If the STATUS 600 = Success, then this message will also contain an AP REG CHALLENGE 601 payload. This is a randomly generated 16 byte challenge to the AP. 603 HEADER 604 Type = 3 605 SessionID = 0x0 607 PAYLOAD 608 REQ ID = from the corresponding Reg-Req message 609 STATUS = Success (1) or Failure (2) based on the known AP database 610 in the AC 611 AP REG CHALLENGE 613 5.2.3 CTP Auth-Req 615 This message is sent by the AP to begin the authentication phase of 616 the connection establishment with the AC. It contains the AP serial 617 number, an AP REG RESPONSE payload, the AP's digital certificate 618 (which contains the AP's public key) and a 16 byte random challenge 619 to the AC. Note that the SessionID field in the packet header is 620 still zero. 622 HEADER 623 Type = 4 624 SessionID = 0x0 626 PAYLOAD 627 REQ ID 628 AP_SERIAL_NUMBER 629 CERTIFICATE 630 AP REG RESPONSE = Digital Signature of the concatenation of the AP 631 SERIAL NUMBER and the AP REG CHALLENGE (from the Reg-Rsp message) 632 AC_REG_CHALLENGE = 16 byte random number challenge sent to 633 authenticate the AC. 635 The response is calculated by the AP and is verified by the AC. For 636 details on the calculation of challenge and response, see the 637 APPENDIX...TBW 639 5.2.4 CTP Auth-Rsp 641 This message is sent by the AC to the AP as an indication of the 642 success or failure of the authentication phase. The AP is only 643 considered to have successfully associated with the AC if both 644 registration and authentication phases complete successfully. 646 HEADER 647 Type = 5 648 SessionID = 16 byte unsigned value generated by the AC. This is 649 set appropriately in this message if the authentication phase was 650 successful. After this message, the AP should use this Session ID in 651 all subsequent messages. 653 PAYLOAD 654 REQ ID = from the corresponding Auth-Req message 655 STATUS = Success (1) if the AP's digital certificate was 656 successfully verified and the AP REG RESPONSE was verified. 657 CERTIFICATE 658 AC REG RESPONSE = Digital Signature of the concatenation of the AP 659 SERIAL NUMBER and the AC REG CHALLENGE (from the Auth-Req message) 660 SESSION KEY = An encrypted payload of the AC generated CTP session 661 key. This is encrypted using the public key of the AP as received in 662 the AP's digital certificate from the Auth-Req message. 664 The STATUS payload indicates whether authentication and registration 665 was processed correctly. If so, Session ID for registration is 666 explicitly provided in the message header. 668 5.2.5 CTP SW-Update-Req 670 This message is sent by the AP to ask the AC whether it should 671 upgrade its own software or not. It simply needs to provide its 672 current software version to the AC. 674 This message MAY also be sent by the AC to the AP which is a command 675 indication for the AP to stop operations and upgrade its software. 677 HEADER 678 Type = 6 679 SessionID = the assigned ID as received in the Auth-Rsp message. 681 PAYLOAD 682 REQ ID 683 AP SERIAL NUMBER 684 SWVersion = Variable length ASCII text specifying the current 685 running software on the AP. 687 5.2.6 CTP SW-Update-Rsp 689 This message is sent by the AC to signal the AP to upgrade its 690 software or by the AP to the AC to indicate to confirm that it has 691 received the upgrade request. When the corresponding request is 692 issued by the AP, the AC will check the SWVersion payload received in 693 the Software-Upgrade-Req for the AP and send a response based on a 694 match. The interpretation of the SWVersion payload is implementation 695 specific. The response by the AC is either "Yes" or "No" which is 696 interpreted through the STATUS payload. If the response by the AC 697 indicates a failure the AP must abandon the registration stage, 698 upgrade its software to the version indicated by the AC. The method 699 by which the software image is exchanged is outside of the scope of 700 this protocol. 702 When the corresponding request is issued by the AC, the AP will 703 simply confirm the reception of the request and abandon it's 704 connected state in order to perform the upgrade. 706 HEADER 707 Type = 7 708 SessionID = the assigned ID as received in the Auth-Rsp message. 710 PAYLOAD 711 REQ ID = from the corresponding SW-Update-Req message 712 STATUS = [Success/Don't Upgrade (1) | Failure/Upgrade (2)] 713 SWVersion [On Failure] = Variable length ASCII text specifying the 714 correct software version the AP should have in order to complete the 715 session registration with the AC. 717 5.2.7 CTP Set-State-Req 719 This message is sent by the AC to modify the operational state of the 720 AP. For example, at some point during an established connection it 721 may be necessary to instruct an AP to go to STANDBY state or initiate 722 a reboot/reset of its state machine. These states are usually 723 entered upon user request 725 The following states are defined and apply to the AP: 727 ACTIVE 729 Indication to the AP that it should exit standby state and should 730 resume full active network state including enabling it's RF 731 interfaces. This is the default state of the AP after successful 732 configuration phase. 734 STANDBY 736 This signifies a state where the AP, although connected to the AC, is 737 in a state whereby no RF connection is allowed. It may be a sent to 738 the AP upon user request. 740 RESET 742 This is used as a command to the AP to change state to initialization 743 state. This may be sent to the AP upon user request or upon failure 744 of any of the phases of the control channel establishment. 746 HEADER 747 Type = 12 748 SessionID = AP session id from registration 750 PAYLOAD 751 REQ ID 752 AP_STATE = [STANDBY(0) | ACTIVE(1) | RESET(2)] 754 5.2.8 CTP_Set-State-Rsp 756 This message is sent by the AP to indicate to the AC that it has 757 changed its operational state as requested. 759 HEADER 760 Type = 13 761 SessionID = AP session id from registration 763 PAYLOAD 764 REQUEST ID = Same ID that was received in the Set-State-Req 765 message. 766 STATUS = [Success (1) | Failure (2)] 767 AP_STATE = [STANDBY(0) | ACTIVE(1) | RESET(2)] 769 The RESET(2) state assumes that the AP would have reset its 770 operations after sending out this message. 772 5.2.9 CTP Poll-Req 774 This message is the keepalive mechanism for the CTP control channel. 775 This is sent by the AP to the AC. The default send frequency for 776 this message is 5 seconds. If no response is received from the AC 777 after sending this message 6 times in a row, then the AP should tear 778 down its CTP control channel state and reattempt to connect to the 779 AC. These values are considered to be defaults. An AP 780 implementation MAY choose to change these values for suitability to 781 network deployment conditions. 783 HEADER 784 Type = 16 785 SessionID = AP session id from registration 787 PAYLOAD 788 REQ ID = ID representing the Poll-Req. Incremented until a 789 corresponding Poll-Rsp is received. 791 5.2.10 CTP Poll-Rsp 792 This message is the keepalive mechanism for the CTP control channel. 793 This is sent by the AC in response to a CTP Poll-Req message received 794 from the AP. The AC SHOULD detect the loss of connectivity with the 795 AP based on the receipt of a Poll-Req message. 797 HEADER 798 Type = 17 799 SessionID = AP session id from registration 801 PAYLOAD 802 REQ ID = ID corresponding to the Poll-Req received. 804 5.2.11 CTP MU-Connect-Req 806 This message is sent by the AP to relay an association request 807 received from an MU to the AC. 809 HEADER 810 Type = 51 811 SessionID = AP session id from registration 813 PAYLOAD 814 REQ ID 815 MU-MAC-Address = MAC Address corresponding to the associating MU 816 NETWORK ID = Network identification where association is taking 817 place 818 RADIO ID = Radio ID where association is taking place 820 5.2.12 CTP MU-Connect-Rsp 822 This message is sent by the AC to authorize the access point to relay 823 an association response to the MU requesting service. If the 824 association is successful, then the AC MAY also include optional 825 payloads such as Policy which can be enforced at the AP. 827 If the association is rejected by the AC, the AP must disallow 828 association of the MU. 830 HEADER 831 Type = 52 832 SessionID = AP session id from registration 834 PAYLOAD 835 REQ ID = from the corresponding MU-Connect-Req message 836 MU-MAC-Address = MAC Address corresponding to the associating MU 837 STATUS = [Success (1) | Failure (2)] 839 5.2.13 CTP MU-Disconnect-Req 840 This message is sent by the AC to request that a specific Mobile Unit 841 session be removed from the AP list of currently connected devices. 842 This operation may be the result of Mobile Unit roaming to a 843 different AP or the result of Mobile Unit session timeout, or user 844 request. 846 The MU-MAC-Address identifies the device in question. 848 HEADER 849 Type = 53 850 SessionID = AP session id from registration 852 PAYLOAD 853 REQ ID = ID for the request. Must increment after every 854 retransmission of this message. 855 MU-MAC-Address = MAC Address corresponding to the MU that is to be 856 disconnected. 857 RADIO ID = Radio ID where disconnection is required. 859 5.2.14 CTP MU-Disconnect-Rsp 861 This message is sent by the AP to indicate that it has successfully 862 processed a disconnect request by the AC. At this point the MU should 863 no longer be associated with the AP. 865 HEADER 866 Type = 54 867 SessionID = AP session id from registration 869 PAYLOAD 870 REQ ID = Same ID that was received in the MU-Disconnect-Req 871 message. 872 MU-MAC-ADDRESS = MAC Address corresponding to the MU that was 873 disconnected 874 STATUS = [Success (1) | Failure (2)] 876 5.2.15 CTP MU-Disconnect-Nfy 878 This message is sent by the AP to the AC to indicate that it has 879 received an explicit disconnection message from the MU. The 880 transmission of this message from the AP is dependent on the MAC 881 layer of the radio technology implemented on the AP as well as the 882 capability of the MU. For example, the radio MAC layer may or may 883 not support an explicit "disconnect" trigger when an MU goes away. 884 Rather, the disconnection is based on a timer. In cases where the 885 disconnection is timer based, the AC may be the appropriate entity to 886 handle idle timer management. However, in the case where there may 887 be a disconnect indication, then the AP must send this message to the 888 AC when and MU disconnects. 890 HEADER: 891 Type = 57 892 SessionID = AP session ID negotiated at registration 894 PAYLOAD 895 MU-MAC-Address = MAC address of Mobile unit that was disconnected 896 NETWORK ID = 898 5.2.16 CTP MU-Authenticate-Req 900 This message is sent by the AP to forward an authentication request 901 to the AC. In the case of 802.1x/EAP authentication, the payload of 902 this packet will include information that the AC will forward to a 903 RADIUS Server 905 HEADER 906 Type = 55 907 SessionID = AP session id from registration 909 PAYLOAD 910 REQ ID 911 The authentication request payload between the AP and the AC 912 carries the request of the MU for authentication. In typical cases 913 this will be the EAP packets from an 802.1x supplicant. 915 5.2.17 CTP MU-Authenticate-Rsp 917 This message is sent by the AC to forward an authentication response 918 to the AP. In the case of 802.1x/EAP authentication, the payload of 919 this packet will include the response from the RADIUS server which 920 will be forwarded to the AP. 922 HEADER 923 Type = 56 924 SessionID � AP session id from registration 926 PAYLOAD 927 REQ ID = from the MU-Authenticate-Req message 928 The Authentication response payload between the AP and the AC 929 carries the response from the authentication server. In typical 930 cases this will be the EAP packets from the Authentication server. 931 STATUS = [Success (1) | Failure (2)] - Note that the authenticator 932 to authentication server interface resides in the AC so the AC does 933 know the state of the authentication. 934 Note: There may be multiple transitions of this message set. 936 5.3 Configuration and Statistics messages 938 These messages correspond to information and command exchanges 939 between AP and AC only after 941 5.3.1 CTP Cap-Req 943 This message is sent by the AP to indicate to the AC the capabilities 944 of this AP in regards to the number of radios and the types of RF 945 technologies that it supports. The AP will encode its capabilities 946 per each RADIO (or interface) that it supports. These are encoded in 947 a variable length embedded attribute format called "capabilities 948 control frames". A type-length-value encoding scheme, similar to the 949 format of payloads of regular control messages, is used to encode the 950 capabilities attributes (ATTs) in the capability control frames. 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Type | Length | Value... 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 The available capability attributes are defined as follows: 960 1) ATT-NUM-RADIOS - number of radios that the AP supports. 962 Type= 1 963 Length= 1 byte 964 Value= 1 through 255 966 2) ATT-RADIO-INFO - the information for each radio that 967 consists of the RADIO-INDEX, RADIO-TYPE, and NUM- 968 NETWORKS. There MUST be exactly ATT-NUM-RADIOS number of 969 unique ATT-RADIO-INFO attributes within the Cap-Req 970 message. 972 Type= 2 973 Length= 3 bytes 974 Value= radio information type as defined below: 976 0 1 2 977 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | RADIO-INDEX | RADIO-TYPE | NUM NETWORKS | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 where 983 RADIO-INDEX is a unique index of the enumeration of the 984 number of radios that the AP supports. The AC will use this 985 value for subsequent configuration and control. 987 RADIO-TYPE is defined as 989 o 802.11a = 1 990 o 802.11b only = 2 991 o 802.11g only = 3 992 o 802.11b and g = 4 993 o 802.11n = 5 994 o 802.15 = 6 995 o 802.16 = 7 996 o 802.20 = 8 997 o All = 255 (this value indicates that 998 all interfaces are configurable 999 to any radio type) 1001 NUM-NETWORKS is the number of unique networks that each 1002 RADIO supports. 1004 3) ATT-NETWORK-INFO - This attribute consists of the unique 1005 information that identifies each network per RADIO-INDEX 1006 and consists of RADIO-INDEX, NETWORK-INDEX and NETWORK- 1007 ID. Each Cap-Req payload MUST contain exactly NUM- 1008 NETWORKS worth of unique ATT-NETWORK-INFO attributes. 1010 Type= 3 1011 Length= 8 bytes 1012 Value= network information type as defined below: 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | RADIO-INDEX | NETWORK-INDEX | NETWORK ID | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | NETWORK ID | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 where 1024 RADIO-INDEX is a unique index of the enumeration of the 1025 number of radios that the AP supports 1027 NETWORK-INDEX is a unique index of the enumeration of the 1028 networks that each RADIO supports 1030 NETWORD-ID is the unique identifier for the network. This 6 1031 byte value MAY be the MAC address for the given network 1032 within the radio. In the case of 802.11 radios, this value 1033 SHOULD be the BSS ID. 1035 4) ATT-VENDOR-ID - name of vendor or manufacturer of AP. 1037 Type= 4 1038 Length= 4 bytes 1039 Value = a 32-bit value containing the IANA assigned 1040 "SMI Network Management Private Enterprise Codes" [3]. 1042 5) ATT-PRODUCT-ID - name of product. 1044 Type= 5 1045 Length= variable length value of string 1046 Value= ASCII string for the name of the product, non- 1047 Null terminated. 1049 HEADER 1050 Type = 20 1051 SessionID = AP session id from registration 1053 PAYLOAD 1054 REQ ID = increments with each retransmission. 1055 The capabilities attributes encoded as TLVs and as defined above. 1057 5.3.2 CTP Cap-Rsp 1059 This message is sent by the AC to acknowledge the capabilities of the 1060 AP. The AC must ack or nak the capabilities for each RADIO-INFO 1061 element that it received in the Cap-Req message. This is 1062 accomplished by sending back exactly ATT-NUM-RADIOS worth of ATT- 1063 RADIO-INFO-ACK for each RADIO-INFO sub-attribute that this AC 1064 supports. 1066 The ATT-RADIO-INFO-ACK is an attribute that contains the RADIO-INDEX 1067 and CAP-STATUS sub-attribute. For each Radio type that the AC 1068 supports, the CAP-STATUS must be set to 1. For each radio type that 1069 the AC does not support, the CAP-STATUS must be set to 0. 1071 Type= 6 1072 Length= 2 bytes 1073 Value= as defined below. 1075 0 1 1076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | RADIO-INDEX | CAP-STATUS | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 HEADER 1082 Type = 21 1083 SessionID = AP session id from registration 1085 PAYLOAD 1086 REQ ID = ID corresponding to the Cap-Req message. 1087 The AC capabilities attribute response encoded as TLVs and as 1088 defined above. 1090 5.3.3 CTP Config-Req 1092 This message is sent by the AP to request configuration from its 1093 master AC. This message must be sent only after a receipt of a 1094 successful Auth-Rsp message from the AC and the verification of the 1095 AC's AC REG RESPONSE payload. 1097 HEADER 1098 Type = 8 1099 SessionID - the assigned ID as received in the Auth-Rsp message. 1101 PAYLOAD 1102 REQ ID 1103 No specific information is required on this message. 1105 5.3.4 CTP Config-Rsp 1107 This message is sent by the AC as a response to a Config-Req message 1108 to provide the configuration parameters for the registered AP. 1110 HEADER 1111 Type = 9 1112 SessionID = AP session id from registration 1113 Sequence Number = Sequence number of current packet. 1115 PAYLOAD 1116 REQ ID = from Config-Req message 1117 STATUS = [Success (1) | Failure (2)] 1118 CONFIG = The type of the configuration payload is defined in 1119 Section 5.3.10. 1121 5.3.5 CTP Config-Ack 1123 This message is sent by the AP to indicate proper reception of an 1124 AP_Config-Rsp message. This message is particularly important in 1125 processing multi-sequenced packets, in particular configuration 1126 updates that require more than one payload for full receipt of 1127 configuration information. 1129 HEADER 1130 Type = 10 1131 SessionID = AP session id from registration 1133 PAYLOAD 1134 None 1136 5.3.6 CTP Config-Status-Notify 1138 This message is used by the AP to indicate to the AC that it has 1139 successfully completed it's configuration as per parameters indicated 1140 by the AP. 1142 HEADER 1143 Type = 11 1144 SessionID = AP session id from registration 1146 PAYLOAD 1147 STATUS 1149 5.3.7 CTP Stats-Notify 1151 This message is sent by the AP to provide periodic operational 1152 statistics to the AC. This message is also used following a correct 1153 configuration establishment to indicate to the AC that the AP is 1154 functionally ready to enter ACTIVE state. 1156 HEADER 1157 Type = 14 1158 SessionID = AP session id from registration 1160 PAYLOAD 1161 STATS - The type of the statistics payload is defined in Section 1162 5.3.10. 1164 5.3.8 CTP Stats-Req 1166 This message is sent by the AC to request statistics information upon 1167 request. It is intended to be used as an interface by an 1168 administrator or management application to query the AP for 1169 instantaneous statistics information. 1171 HEADER 1172 Type = 18 1173 SessionID = AP session id from registration 1175 PAYLOAD 1176 None 1178 5.3.9 CTP Stats-Rsp 1180 This message is sent by the AP to provide operational statistics to 1181 the AC as per the Stats-Req message. It is similar in format to the 1182 Stats-Notify message. 1184 HEADER 1185 Type = 19 1186 SessionID = AP session id from registration 1188 PAYLOAD 1189 STATS = The type of the statistics payload is defined in Section 1190 5.3.10 1192 5.3.10 Configuration and Statistics 1194 Two data representations were considered for the CTP configuration 1195 and statistics payload. The first data representation considered was 1196 a TLV representation where all the variables for the statistics and 1197 configuration would be defined as groups of TLVs. Given the nature of 1198 CTP as a radio agnostic protocol and the complexity of the statistics 1199 and configuration of the 802.11 protocols with multiple networks per 1200 radio a TLV representation might be cumbersome and not extensible. 1202 Most of today's network devices in both the enterprise and the 1203 carrier space employ the Simple Network Management Protocol. Thus, it 1204 is natural to assume that most, if not all, APs will contain an 1205 embedded SNMP agent able to decode SMI representations. Using SMI 1206 representations for configuration and statistics variables can speed 1207 up deployment of CTP without incurring additional cost for the APs. 1208 Our recommendation is to reuse the 802.11 MIBs where applicable for 1209 the CTP configuration and statistics message payload. MIB extensions 1210 should be defined where the corresponding IEEE MIBs are not 1211 sufficient. Upon reception of the message the CTP daemon should 1212 forward the configuration and statistics message payload to the SNMP 1213 daemon for further decoding and processing of the SMI O.I.D.s. 1215 5.4 CTP Data Messages 1217 The CTP data messages use the same CTP header as the control and 1218 other messages. If the Type field is 15 (CTP-Data), then the Policy 1219 field of the header is used by the AC to tag the data for special 1220 handling. The interpretation of the Policy field is left up to the 1221 implementation. An example of its use is as follows: 1223 Data packet coming into the AC from the wired network is a voice 1224 packet as indicated by the TOS or DSCP markings in the IP header. 1225 This TOS/DSCP byte will be copied to the outer transport header for 1226 proper priority handling within the network between the AP and the 1227 AC. However, for appropriate classification at the AP, the AC sets 1228 the Policy field to a value that allows the AP to prioritize this 1229 packet over other data packets that may have a lower priority. 1230 Similarly in the reverse direction, the MU may have set the 1231 appropriate fields in the original IP header, but the AP can 1232 interpret those bits and map them to the Policy field in the CTP-Data 1233 header for special dispensation at the AC. 1235 5.4.1 CTP Data 1237 This message is utilized as the transport of MU layer data. The 1238 contents of the message body are not interpreted by the AP layer 1239 other than sending it to the MAC layer of the AP. 1241 HEADER 1242 Type = 15 1243 SessionID = AP session id from registration 1244 Policy = as set by the implementation 1246 PAYLOAD 1247 802.3 frame 1249 6. State Machines 1251 This state machine in Figure 4 indicates the logical state 1252 transitions of the CTP session establishment. 1254 user-request/reset 1255 +----------------------------------------------+ 1256 | | 1257 | | 1258 | | 1259 | | 1260 | | 1261 V +-----------+ | 1262 +------+ Success | Control | Success +----------+ 1263 | Init |------------->| Session |--------->| Active | 1264 +------+ | Establish | +----------+ 1265 ^ +-----------+ ^ | 1266 | | | | 1267 | | | | 1268 | | user-req | |user-req 1269 | | | | 1270 | | | | 1271 | Failure | | V 1272 +--------------------------+ +----------+ 1273 | Standby | 1274 +----------+ 1276 Figure 4 - Simple CTP state machine 1278 6.1 Init 1280 This state represents the boot state, and initialization of the 1281 hardware. Entry into this state is either Failure of the Control 1282 Session Establishment or user-request or reset signal from the Active 1283 state 1285 6.2 Control Channel Establishment 1287 Once Initialization completes the AP initiates the control channel 1288 establishment phase of the connection. Any phase within this state 1289 that fails because of a STATUS=FAILURE or no response from either 1290 device will result in a failure of the whole phase and go back to 1291 initialization. A successful completion of the control session 1292 establishment process will include 1293 Registration 1294 Authentication 1295 Software Upgrade Notification 1296 Capability negotiation 1297 Configuration Request 1298 Configuration Response 1299 Configuration Ack. 1301 Upon receipt of a successful Config-Ack from the AP, the AP and AC 1302 session for the AP are put into ACTIVE state. 1304 6.3 Active State 1306 Once confirmation of successful registration is received the device 1307 now has a properly established communications/tunneling session with 1308 the AC. The Authentication response MUST have indicated a valid CTP 1309 session ID by which this tunnel is registered on the AC. So in this 1310 state, the SessionId MUST be non-zero. 1312 This state persists until device terminates or communications with 1313 the AC are interrupted. To assist in the detection of connection 1314 termination, the device MUST implement the CTP Poll-Req and Poll-Rsp 1315 messages as described previously. Another method of exiting this 1316 state is with an explicit Set-State message that may be only be 1317 initiated by the AC to the AP. 1319 6.4 Standby State 1321 At some time during the operation, it may be necessary to instruct an 1322 AP to halt its current operation, ie. to switch off the RF 1323 interface(s) on the AP . This is done by the Set-State message. The 1324 device will remain in this state, until explicitly told by the AC to 1325 resume operation also using the Set-State message. 1327 7. Security Considerations 1329 Since the AP and AC can be separated over any arbitrary L3 cloud, 1330 first and foremost there is a need for a secure binding between the 1331 AC and AP. A control channel security association is required 1332 between the AC and AP. The AC and AP must go through a mutual 1333 authentication phase during a registration and authentication process 1334 and form a security association. A couple of assumptions are made to 1335 ensure this security association is created. First, there must be a 1336 secure mechanism to get the digital certificates onto the APs and ACs 1337 and that process must be run either at the factory or prior to device 1338 deployment. Secondly, the placement of the AP ID (in most cases the 1339 AP serial number) in a data store on the AC assumes a secure 1340 insertion mechanism. This may be a manual process or other secure ID 1341 provisioning methods may be employed. Once the registration and 1342 authentication process has successfully completed then the control 1343 traffic is encrypted. The traffic is confined to control, 1344 configuration and management traffic between the AC and AP. 1346 There is an optional data path security association that can also be 1347 created. It is believed that for security sensitive applications and 1348 deployments there will always be an end to end encrypted tunnel of MU 1349 data traffic. Therefore, a data path encryption mechanism is 1350 considered optional and configurable based on security policy. 1352 STA authentication and security policy enforcement is done centrally 1353 in the AC but the mechanisms are out of scope for this protocol. 1355 8. References 1357 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1358 Levels", BCP 14, RFC 2119, March 1997 1360 [2] Yang, L., et. al., "CAPWAP Problem Statement", February 2004, 1361 . 1364 [3] "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", 1365 January 2002, . 1367 [4] Eastlake, D., et. al., "Randomness Recommendations for 1368 Security", December 1994, RFC 1750. 1370 [5] Whiting, et al., "Counter with CBC-MAC (CCM)", September 2003, 1371 RFC 3610. 1373 9. Author's Addresses 1375 Paulo Francisco 1376 Chantry Networks 1377 1900 Minnesota Court 1378 Mississauga, ON M8V 1E5 1379 Canada 1381 Phone: +1 905-567-6900 1382 Email: paulo@chantrynetworks.com 1384 Inderpreet Singh 1385 Chantry Networks 1386 1900 Minnesota Court 1387 Mississauga, ON M8V 1E5 1388 Canada 1390 Phone: +1 905-567-6900 1391 Email: isingh@chantrynetworks.com 1393 Floyd Backes 1394 Propagate Networks 1395 125 Nagog Park 1396 Acton, MA 01720 1397 USA 1399 Phone: +1 978-264-4884 1400 Email: fbackes@propagatenet.com 1402 10. Appendix I - Registration and Authentication 1404 The registration and authentication phase of CTP is detailed below. 1406 +----+ +----+ 1407 | AP | | AC | 1408 +----+ +----+ 1409 Reg-Req(AP-ID) 1410 ----------------------------------------------> 1412 Reg-Rsp(Status,AP-challenge) 1413 <---------------------------------------------- 1415 Auth-Req(AP-ID,AP-cert,AP-resp,AC-challenge) 1416 -----------------------------------------------> 1418 Auth-Rsp(Status,AC-cert,AC-rsp,Session-Key) 1419 <----------------------------------------------- 1421 AP-ID - AP SERIAL NUMBER attribute. This attribute is assumed to be 1422 available in a data store in the AC as well as being factory burnt-in 1423 in the AP device. The AC will respond with a STATUS=Success in the 1424 Reg-Rsp message if there is a match in its data store for the given 1425 AP-ID 1427 AP-challenge - is a 16 byte random number generated using [4] as 1428 guidelines for the randomness of the challenge. 1430 AP-cert - Is a digital certificate assumed to be available on the AP 1431 prior to its Registration request. The mechanism to get the 1432 certificate onto the AP is out of scope for this document. 1434 AP-resp - Is a digital signature over the MD5 hash of the AP- 1435 challenge concatenated with the AP-ID. 1437 S-ap(H-md5(AP-challenge|AP-ID)) 1439 AP-challenge - is a 16 byte random number generated for subsequent 1440 authentication of the AC. 1442 AC-cert - Is a digital certificate of the AC that is assumed to be 1443 available on the AC prior to sending the Reg-Rsp message. The 1444 mechanism to get the certificate onto the AC is out of scope for this 1445 document. 1447 AC-resp - is a digital signature over the MD5 hash of the AC- 1448 challenge concatenated with the encrypted session key. 1449 S-ac(H-md5(AC-challenge|Enc-ac-p(SessionKey))) 1451 Session Key - is actually the encrypted randomly generated session 1452 encryption keying material. The AC uses the public key of the AP to 1453 encrypted the session encryption key.[Key generation algorithm is 1454 TBD] 1456 1. The AP sends a Reg-Req message with its AP SERIAL NUMBER. If 1457 it does not receive a Reg-Req within 3 seconds, it must resend 1458 the Reg-Req message. 1459 2. Upon receipt of the Reg-Req message, the AC checks its data 1460 store for the AP SERIAL NUMBER. If it exists then the AC 1461 sends back a Reg-Rsp message with STATUS payload with Success 1462 (1) attribute and an AP CHALLENGE payload. If the AP SERIAL 1463 NUMBER does not exist, then a Reg-Rsp message with a STATUS 1464 payload of Failure (2) is sent back. 1465 3. The AP will take the AP CHALLENGE payload, concatenate it with 1466 the AP SERIAL NUMBER and calculate an AP RESPONSE as shown 1467 above and send it back to the AC along with an AC CHALLENGE 1468 payload and its own digital CERTIFICATE payload in an Auth-Req 1469 message. 1470 4. Upon receipt of the Auth-Req message the AC will 1471 a. Verify the AP's digital certificate 1472 b. Verify the AP RESPONSE, which was the digital signature of 1473 the AP over the hash of the AP CHALLENGE and the AP SERIAL 1474 NUMBER. This is done with the public key of the AP. 1475 c. If both a) and b) are verified correctly, then the STATUS 1476 payload will contain Success (1). Otherwise it will 1477 contain Failure (2). 1478 d. If Success, then the AC will add its own CERTIFICATE to 1479 the Auth-Rsp message 1480 e. Encrypt the session encryption keys with the public key of 1481 the AP. 1482 f. Generate a unique SessionID to be used in subsequent CTP 1483 messages. 1485 g. Send back an Auth-Rsp message with STATUS, CERTIFICATE, AC 1486 RESPONSE and SESSION KEY payloads with the SessionID in 1487 the CTP header. 1488 5. Upon receipt of the Auth-Rsp message, the AP will 1489 a. Verify the AC's digital certificate 1490 b. Verify the AC RESPONSE which was the digital signature of 1491 the AC over the hash of the AC CHALLENGE and the encrypted 1492 session encryption key. 1493 c. Decrypt the encrypted session encryption key with its own 1494 private key 1495 d. Store the SessionID which will be used in each subsequent 1496 CTP message. 1497 6. All CTP control messages after the Auth-Rsp will be sent with 1498 TBD encryption and per packet authentication mechanism. 1499 (Current recommended scheme is AES-CCM as per [5].) 1501 TBW - Rekeying mechanism 1503 Intellectual Property Statement 1505 The IETF takes no position regarding the validity or scope of any 1506 intellectual property or other rights that might be claimed to 1507 pertain to the implementation or use of the technology described in 1508 this document or the extent to which any license under such rights 1509 might or might not be available; neither does it represent that it 1510 has made any effort to identify any such rights. Information on the 1511 IETF's procedures with respect to rights in standards-track and 1512 standards-related documentation can be found in BCP-11. Copies of 1513 claims of rights made available for publication and any assurances of 1514 licenses to be made available, or the result of an attempt made to 1515 obtain a general license or permission for the use of such 1516 proprietary rights by implementors or users of this specification can 1517 be obtained from the IETF Secretariat. 1519 The IETF invites any interested party to bring to its attention any 1520 copyrights, patents or patent applications, or other proprietary 1521 rights which may cover technology that may be required to practice 1522 this standard. Please address the information to the IETF Executive 1523 Director. 1525 Full Copyright Statement 1527 Copyright (C) The Internet Society (2004). All Rights Reserved. 1529 This document and translations of it may be copied and furnished to 1530 others, and derivative works that comment on or otherwise explain it 1531 or assist in its implementation may be prepared, copied, published 1532 and distributed, in whole or in part, without restriction of any 1533 kind, provided that the above copyright notice and this paragraph are 1534 included on all such copies and derivative works. However, this 1535 document itself may not be modified in any way, such as by removing 1536 the copyright notice or references to the Internet Society or other 1537 Internet organizations, except as needed for the purpose of 1538 developing Internet standards in which case the procedures for 1539 copyrights defined in the Internet Standards process must be 1540 followed, or as required to translate it into languages other than 1541 English. 1543 The limited permissions granted above are perpetual and will not be 1544 revoked by the Internet Society or its successors or assignees. 1546 This document and the information contained herein is provided on an 1547 AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1548 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1549 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1550 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1551 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1553 Acknowledgment 1555 Funding for the RFC Editor function is currently provided by the 1556 Internet Society.