draft-singh-capwap-ctp-00.txt   draft-singh-capwap-ctp-01.txt 
Operations Group Operations Group
Internet Draft I. Singh Internet Draft I. Singh
Document: draft-singh-capwap-ctp-00.txt P. Francisco Document: draft-singh-capwap-ctp-01.txt P. Francisco
K. Pakulski
Chantry Networks Chantry Networks
F. Backes F. Backes
Propagate Networks AutoCell Laboratories
Expires: November 2004 May 2004 Expires: October 2005 April 2005
CAPWAP Tunneling Protocol (CTP) CAPWAP Tunneling Protocol (CTP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 3 of RFC3667. By submitting this Internet-
Draft, each author represents that any applicable patent or other
IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2004. This Internet-Draft will expire on October 4, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
With the overwhelming choice of proprietary implementations of With the overwhelming choice of proprietary implementations of
centralized control and management of wireless access points and centralized control and management of wireless access points and
access controllers there is a great demand for a standard protocol access controllers there is a great demand for a standard protocol
and architecture that enables the deployment of large scale wireless and architecture that enables the deployment of large scale wireless
networks. networks.
This document describes the CAPWAP Tunneling Protocol, a protocol This document describes the CAPWAP Tunneling Protocol, a protocol
that allows for the centralized control and provisioning of a large that allows for the centralized control and provisioning of a large
number of wireless access points from access controllers. It is number of wireless access points from access controllers. It is
supported by an architecture where the MAC layer of the RF technology supported by an architecture where the MAC layer of the RF technology
is terminated within the AP. This allows for the protocol to be is terminated within the AP. This allows for the protocol to be
extensible to multiple radio technologies. It assumes an IP extensible to multiple radio technologies. It assumes an IP
connection between the access points and access controllers and has connection between the access points and access controllers and has
signaling primitives to enable wireless station mobility between signaling primitives to enable wireless station mobility between
access points. Therefore, seamless Layer 3 subnet mobility is access points. Therefore, seamless Layer 3 subnet mobility is
enabled by this protocol. seamlessly enabled by this protocol.
Table of Contents Table of Contents
1. Definitions....................................................4 1. Definitions....................................................4
1.1 Conventions used in this document..........................4 1.1 Conventions used in this document..........................4
1.2 Terminology................................................4 1.2 Terminology................................................4
2. Introduction...................................................4 2. Introduction...................................................4
2.1 Out of scope...............................................6 2.1 Out of scope...............................................6
2.1.1 Secure discovery of AP and AC.........................6 2.1.1 Secure discovery of AP and AC.........................6
2.1.2 AP image management...................................6 2.1.2 AP image management...................................6
skipping to change at page 2, line 34 skipping to change at page 2, line 39
3.1 Control and Status Messages................................7 3.1 Control and Status Messages................................7
3.2 Configuration and Statistics messages......................7 3.2 Configuration and Statistics messages......................7
3.3 Data Messages..............................................8 3.3 Data Messages..............................................8
4. CTP Packets....................................................8 4. CTP Packets....................................................8
4.1 CTP Header format..........................................8 4.1 CTP Header format..........................................8
4.2 Messages...................................................9 4.2 Messages...................................................9
4.3 Message Payloads..........................................10 4.3 Message Payloads..........................................10
5. Message descriptions..........................................13 5. Message descriptions..........................................13
5.1 Message State Control.....................................13 5.1 Message State Control.....................................13
5.2 Control and Status messages...............................13 5.2 Control and Status messages...............................13
5.2.1 CTP Reg-Req..........................................13 5.2.1 CTP_Reg-Req..........................................13
5.2.2 CTP Reg-Rsp..........................................13 5.2.2 CTP Reg-Rsp..........................................14
5.2.3 CTP Auth-Req.........................................14 5.2.3 CTP Auth-Req.........................................14
5.2.4 CTP Auth-Rsp.........................................14 5.2.4 CTP Auth-Rsp.........................................15
5.2.5 CTP SW-Update-Req....................................15 5.2.5 CTP SW-Update-Req....................................15
5.2.6 CTP SW-Update-Rsp....................................15 5.2.6 CTP SW-Update-Rsp....................................16
5.2.7 CTP Set-State-Req....................................16 5.2.7 CTP_Set-State-Req....................................16
5.2.8 CTP Set-State-Rsp....................................17 5.2.8 CTP_Set-State-Rsp....................................17
5.2.9 CTP Poll-Req.........................................17 5.2.9 CTP Poll-Req.........................................17
5.2.10 CTP Poll-Rsp........................................17 5.2.10 CTP Poll-Rsp........................................18
5.2.11 CTP MU-Connect-Req..................................18 5.2.11 CTP_MU-Connect-Req..................................18
5.2.12 CTP MU-Connect-Rsp..................................18 5.2.12 CTP_MU-Connect-Rsp..................................18
5.2.13 CTP MU-Disconnect-Req...............................18 5.2.13 CTP_MU-Disconnect-Req...............................19
5.2.14 CTP MU-Disconnect-Rsp...............................19 5.2.14 CTP_MU-Disconnect-Rsp...............................19
5.2.15 CTP MU-Disconnect-Nfy...............................19 5.2.15 CTP_MU-Disconnect-Nfy...............................20
5.2.16 CTP MU-Authenticate-Req.............................20 5.2.16 CTP MU-Authenticate-Req.............................20
5.2.17 CTP MU-Authenticate-Rsp.............................20 5.2.17 CTP MU-Authenticate-Rsp.............................20
5.3 Configuration and Statistics messages.....................21 5.3 Configuration and Statistics messages.....................21
5.3.1 CTP Cap-Req..........................................21 5.3.1 CTP Cap-Req..........................................21
5.3.2 CTP Cap-Rsp..........................................23 5.3.2 CTP Cap-Rsp..........................................24
5.3.3 CTP Config-Req.......................................24 5.3.3 CTP Config-Req.......................................25
5.3.4 CTP Config-Rsp.......................................24 5.3.4 CTP Config-Rsp.......................................25
5.3.5 CTP Config-Ack.......................................24 5.3.5 CTP Config-Ack.......................................25
5.3.6 CTP Config-Status-Notify.............................25 5.3.6 CTP_Config-Status-Notify.............................26
5.3.7 CTP Stats-Notify.....................................25 5.3.7 CTP_Stats-Notify.....................................26
5.3.8 CTP Stats-Req........................................25 5.3.8 CTP Stats-Req........................................26
5.3.9 CTP Stats-Rsp........................................26 5.3.9 CTP Stats-Rsp........................................27
5.3.10 Configuration and Statistics........................26 5.3.10 Configuration and Statistics........................27
5.4 CTP Data Messages.........................................26 5.4 CTP_Data Messages.........................................27
5.4.1 CTP Data.............................................27 5.4.1 CTP_Data.............................................28
6. State Machines................................................28 6. State Machines................................................29
6.1 Init......................................................28 6.1 Init......................................................29
6.2 Control Channel Establishment.............................28 6.2 Control Channel Establishment.............................29
6.3 Active State..............................................29 6.3 Active State..............................................30
6.4 Standby State.............................................29 6.4 Standby State.............................................30
7. Security Considerations.......................................29 7. Authentication, Encryption and Session Key generation.........30
8. References....................................................30 7.1 Authentication............................................30
9. Author's Addresses............................................30 7.2 Encryption................................................33
10. Appendix I - Registration and Authentication.................31 7.3 Session Key refresh and generation........................35
Intellectual Property Statement..................................33 8. Security considerations.......................................36
9. References....................................................36
10. Author's Addresses...........................................37
Intellectual Property and Copyright Stattements .............37
1. Definitions 1. Definitions
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1]
1.2 Terminology 1.2 Terminology
AP - Access Point - The network device that includes both the AP ° Access Point - The network device that includes both the
wireless termination point as well as the implementation of a wireless termination point as well as the implementation of a
specific radio technology management layer. specific radio technology management layer.
AC - Access Controller - A centralized network entity that controls, AC - Access Controller - A centralized network entity that controls,
configures and manages one or more than one APs. configures and manages one or more than one APs.
MU - Mobile Unit - A wireless device which is also an IP node capable MU - Mobile Unit - A wireless device which is also an IP node capable
of dynamic change in its association with an Access Point. of dynamic change in its association with an Access Point.
2. Introduction 2. Introduction
skipping to change at page 6, line 9 skipping to change at page 6, line 9
for example. By bridging the MU data traffic locally at the AP's for example. By bridging the MU data traffic locally at the AP's
network, and still controlling the authentication centrally via the network, and still controlling the authentication centrally via the
AC, the user is able to forgo the possibility of the data traffic AC, the user is able to forgo the possibility of the data traffic
having to traverse the slow WAN link upstream and then again having to traverse the slow WAN link upstream and then again
downstream to access, for example, a local printer. In this downstream to access, for example, a local printer. In this
centralized architecture solution of CTP, the layer 2 wireless centralized architecture solution of CTP, the layer 2 wireless
termination point and the MAC layer are fully implemented in the AP termination point and the MAC layer are fully implemented in the AP
as shown in Figure 2, which enables this type of feature. as shown in Figure 2, which enables this type of feature.
+--+--+ +----+------+ +--+--+ +----+------+
Control <===>| | (Control) | | Control <===>| | | |
| CTP |<===========>|WirelessMAC| | CTP |<===========>|WirelessMAC|
Data <--->| | | | Data <--->| | | |
+--+--+ +----+------+ +--+--+ +----+------+
^ ^ ^ ^
| +-----------+ | | +-----------+ |
| | | | | | | |
Data (optional) <-------+--->| L2 bridge |<---+ Data (optional) <-------+--->| L2 bridge |<---+
| (Data) | | |
+-----------+ +-----------+
Figure 2 - CTP and MAC interaction in an AP Figure 2 - CTP and MAC interaction in an AP
2.1 Out of scope 2.1 Out of scope
The following areas are out of scope for this version of the The following areas are out of scope for this version of the
protocol. protocol.
2.1.1 Secure discovery of AP and AC. 2.1.1 Secure discovery of AP and AC.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
is available in the transport layer headers. As such, it is not is available in the transport layer headers. As such, it is not
indicated below. indicated below.
4.1 CTP Header format 4.1 CTP Header format
Figure 3 describes the CTP message header format: Figure 3 describes the CTP message header format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |0|0|0|0|E| Type | Policy | Reserved | | Ver |0|0|0|P|E| Type | Policy | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Id. | Length | | Session Id. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Payload... | Message Payload...
+-+-+-+-+ +-+-+-+-+
Figure 3 - CTP Header format Figure 3 - CTP Header format
Ver Field Ver Field
This field identifies the version of the protocol. It is 3 bits of This field identifies the version of the protocol. It is 3 bits of
data. For this specification the version field is 0. data. For this specification the version field is 0.
Flags Field Flags Field
This field is a bitmask of 5 bits that represents special CTP This field is a bitmask of 5 bits that represents special CTP
processing. Bits 3, 4, 5 and 6 are undefined and MUST be zero (0). processing. Bits 3, 4, and 5 are undefined and MUST be zero (0).
Bit #7 as follows: Bit #6 and #7 as follows:
Bit P ° Payload Header
1 indicates that the CTP header is followed by a CTP payload
header (see 5.3.1)
0 indicates that there is no CTP payload header
Bit E - Data path Encryption Bit E - Data path Encryption
1 indicates that the CTP-Data message type data is encrypted 1 indicates that the CTP-Data message type data is encrypted
0 indicates that the CTP-Data message is in the clear 0 indicates that the CTP-Data message is in the clear
Type Field Type Field
This is a 1 byte field that identifies the message type. The message This is a 1 byte field that identifies the message type. The message
types are identified in Section 4.2. types are identified in Section 4.2.
skipping to change at page 10, line 45 skipping to change at page 11, line 4
through the exchange of relevant Type-Length-Value (TLV) elements. through the exchange of relevant Type-Length-Value (TLV) elements.
Each element is encoded as follows: Each element is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
One of the element types as defined below One of the element types as defined below
Length Length
Total length of the value field Total length of the type + length + value fields
Value Value
Value Value
Several elements may be combined in sequence to provide a full Several elements may be combined in sequence to provide a full
payload definition. payload definition.
Note: In order to properly utilize TLVs, the length field of the CTP Note: In order to properly utilize TLVs, the length field of the CTP
header must be properly calculated and includes the sum of the length header must be properly calculated and includes the sum of the length
fields of all TLVs in the payload. fields of all TLVs in the payload.
The following provides a list of TLVs as defined in this version of The following provides a list of TLVs as defined in this version of
the protocol: the protocol:
Definition Type Length Description Definition Type Length Description
(bytes) (bytes)
--------------------------------------------------------------------- ---------------------------------------------------------------------
STATUS 1 1 Explicit indication of the STATUS 1 4 Explicit indication of the
response to requests messages. response to requests messages.
Values for STATUS are the same Values for STATUS are the same
across all messages: across all messages:
0 - Undefined 0 - Undefined
1 - Success 1 - Success
2 Ė Failure 2 ° Failure
SWVersion 2 Variable ASCII text representation of SWVersion 2 Variable ASCII text representation of
the AP software version the AP software version
number. number.
AP SERIAL_NUMBER 3 Variable Unique ASCII representation of AP SERIAL_NUMBER 3 16 Unique ASCII representation of
the Serial number of AP. This the Serial number of AP. This
serial number of the AP must serial number of the AP must
be a priori available to the be a priori available to the
AC. Method of getting this AC. Method of getting this
serial number to the AC is out serial number to the AC is out
of scope for this document. of scope for this document.
AP REG_CHALLENGE 4 16 A 16 byte random challenge AP REG_CHALLENGE 4 16 A 16 byte random challenge
generated by the AC, to be generated by the AC, to be
used by AP upon registration. used by AP upon registration.
AP REG_RESPONSE 5 16 A 16 byte AP calculated AP REG_RESPONSE 5 16 A 16 byte AP calculated
response to AP REG CHALLENGE response to AP REG CHALLENGE
AC REG CHALLENGE 6 16 A 16 byte random challenge AC_IPADDR LIST 6 Variable List of AC IP addresses with
which said AP should attempt
to connect
CONFIG 7 variable Value contains a [SNMP] set of
OIDs of encoded configuration
elements
AC REG CHALLENGE 8 16 A 16 byte random challenge
generated by the AP, to be generated by the AP, to be
used by AC upon registration used by AC upon registration
request. request.
AC REG_RESPONSE 7 16 A 16 byte AC calculated AC REG_RESPONSE 9 16 A 16 byte AC calculated
response to AC REG CHALLENGE response to AC REG CHALLENGE
AC_IPADDR LIST 8 Variable List of AC IP addresses with NETWORK ID 10 4 Network ID with which a given
which said AP should attempt
to connect
NETWORK ID 9 4 Network ID with which a given
radio in the AP is associated. radio in the AP is associated.
This value is unique as it is This value is unique as it is
calculated by the AC upon the calculated by the AC upon the
provisioning phase of the AP provisioning phase of the AP
and provided to it in the and provided to it in the
Config-Rsp message. In the Config-Rsp message. In the
case of 802.11 radio case of 802.11 radio
technology, this is the technology, this is the
Extended Service Set (ESS) to Extended Service Set (ESS) to
which the AP belongs. This is which the AP belongs. This is
a 32 bit integer represent- a 32 bit integer represent-
ation of the ESS. For other ation of the ESS. For other
radio technologies, this is a radio technologies, this is a
unique value representing the unique value representing the
network that the radio is a network that the radio is a
member of. member of.
CONFIG 10 variable Value contains a AP_STATE 11 4 Value contains indication of
[SNMP] set OIDs of encoded
configuration elements
AP_STATE 11 1 Value contains indication of
AP state: AP state:
0=Standby 0=Standby
1=Active 1=Active
2=Reset 2=Reset
SESSION_KEY 12 16 Encrypted session encryption SESSION_KEY 12 19 Encrypted session encryption
key to secure AP to/from AC key to secure AP to/from AC
communications. communications.
STATS 13 Variable Value contains a STATS 13 Variable Value contains a
[SNMP] set of OIDs of encoded [SNMP] set of OIDs of encoded
statistics elements statistics elements
CERTIFICATE 14 Variable Digital certificate
credentials of the AP or AC
RADIO ID 15 1 Index number of the radio as RADIO ID 15 1 Index number of the radio as
learnt during the Capabilities learnt during the Capabilities
exchange. exchange.
REQ ID 16 1 Message identification to REQ ID 16 1 Message identification to
match request and response match request and response
messages. messages.
AUTH_PAYLOAD 17 Variable Payload TLV to include
Encapsulation of MU
Authentication/Authorization
Messages. Typically EAP
frames.
CERTIFICATE 18 Variable Digital certificate
credentials of the AP or AC
5. Message descriptions 5. Message descriptions
5.1 Message State Control 5.1 Message State Control
Unless otherwise stated, every message that is a "request" type Unless otherwise stated, every message that is a "request" type
includes a REQ ID payload inserted by the sender of the message. includes a REQ ID payload inserted by the sender of the message.
This is sent so as to aid in the match of messages that are received This is sent so as to aid in the match of messages that are received
as "responses". After the transmission of each request, the source as "responses". After the transmission of each request, the source
will wait up to 2 seconds for the reception of the response. If a will wait up to 2 seconds for the reception of the response. If a
response is not received, the source will retransmit the packet up to response is not received, the source will retransmit the packet up to
3 times. If after 3 attempts a response is still not received the 3 times. If after 3 attempts a response is still not received the
source aborts the session and resets its state machine. If the source aborts the session and resets its state machine. If the
source is the AP, the AP shall resume registration operations. source is the AP, the AP shall resume registration operations.
Correspondingly the AC will simply delete the AP session from its Correspondingly the AC will simply delete the AP session from its
database and drop all packets which are from unregistered APs. database and drop all packets which are from unregistered APs.
5.2 Control and Status messages 5.2 Control and Status messages
5.2.1 CTP Reg-Req 5.2.1 CTP_Reg-Req
This message is used by the AP to request registration with the AC. This message is used by the AP to request registration with the AC.
This message is initiated by the AP after successful secure discovery This message is initiated by the AP after successful secure discovery
and following the hardware and software initialization sequence of and following the hardware and software initialization sequence of
the AP. The Session ID of this message is set to 0x0000 because the the AP. The Session ID of this message is set to 0x0000 because the
AC will subsequently assign a Session ID upon successful AC will subsequently assign a Session ID upon successful
authentication. This message requires a mandatory payload, namely authentication. This message requires a mandatory payload, namely
"AP Serial Number". "AP Serial Number".
skipping to change at page 14, line 41 skipping to change at page 15, line 8
PAYLOAD PAYLOAD
REQ ID REQ ID
AP_SERIAL_NUMBER AP_SERIAL_NUMBER
CERTIFICATE CERTIFICATE
AP REG RESPONSE = Digital Signature of the concatenation of the AP AP REG RESPONSE = Digital Signature of the concatenation of the AP
SERIAL NUMBER and the AP REG CHALLENGE (from the Reg-Rsp message) SERIAL NUMBER and the AP REG CHALLENGE (from the Reg-Rsp message)
AC_REG_CHALLENGE = 16 byte random number challenge sent to AC_REG_CHALLENGE = 16 byte random number challenge sent to
authenticate the AC. authenticate the AC.
The response is calculated by the AP and is verified by the AC. For The response is calculated by the AP and is verified by the AC. For
details on the calculation of challenge and response, see the details on the calculation of challenge and response, see Section 7
APPENDIX...TBW
5.2.4 CTP Auth-Rsp 5.2.4 CTP Auth-Rsp
This message is sent by the AC to the AP as an indication of the This message is sent by the AC to the AP as an indication of the
success or failure of the authentication phase. The AP is only success or failure of the authentication phase. The AP is only
considered to have successfully associated with the AC if both considered to have successfully associated with the AC if both
registration and authentication phases complete successfully. registration and authentication phases complete successfully.
HEADER HEADER
Type = 5 Type = 5
skipping to change at page 15, line 39 skipping to change at page 16, line 5
This message MAY also be sent by the AC to the AP which is a command This message MAY also be sent by the AC to the AP which is a command
indication for the AP to stop operations and upgrade its software. indication for the AP to stop operations and upgrade its software.
HEADER HEADER
Type = 6 Type = 6
SessionID = the assigned ID as received in the Auth-Rsp message. SessionID = the assigned ID as received in the Auth-Rsp message.
PAYLOAD PAYLOAD
REQ ID REQ ID
AP SERIAL NUMBER
SWVersion = Variable length ASCII text specifying the current SWVersion = Variable length ASCII text specifying the current
running software on the AP. running software on the AP.
5.2.6 CTP SW-Update-Rsp 5.2.6 CTP SW-Update-Rsp
This message is sent by the AC to signal the AP to upgrade its This message is sent by the AC to signal the AP to upgrade its
software or by the AP to the AC to indicate to confirm that it has software or by the AP to the AC to indicate to confirm that it has
received the upgrade request. When the corresponding request is received the upgrade request. When the corresponding request is
issued by the AP, the AC will check the SWVersion payload received in issued by the AP, the AC will check the SWVersion payload received in
the Software-Upgrade-Req for the AP and send a response based on a the Software-Upgrade-Req for the AP and send a response based on a
match. The interpretation of the SWVersion payload is implementation match. The interpretation of the SWVersion payload is implementation
specific. The response by the AC is either "Yes" or "No" which is specific. The response by the AC is either "Yes" or "No" which is
interpreted through the STATUS payload. If the response by the AC interpreted through the STATUS payload. If the response by the AC
indicates a failure the AP must abandon the registration stage, indicates a failure the AP must abandon the registration stage,
upgrade its software to the version indicated by the AC. The method upgrade its software to the version indicated by the AC. The method
by which the software image is exchanged is outside of the scope of by which the software image is exchanged is outside of the scope of
this protocol. this protocol.
When the corresponding request is issued by the AC, the AP will When the corresponding request is issued by the AC, the AP will
simply confirm the reception of the request and abandon it's simply confirm the reception of the request and abandon its
connected state in order to perform the upgrade. connected state in order to perform the upgrade.
HEADER HEADER
Type = 7 Type = 7
SessionID = the assigned ID as received in the Auth-Rsp message. SessionID = the assigned ID as received in the Auth-Rsp message.
PAYLOAD PAYLOAD
REQ ID = from the corresponding SW-Update-Req message REQ ID = from the corresponding SW-Update-Req message
STATUS = [Success/Don't Upgrade (1) | Failure/Upgrade (2)] STATUS = [Success/Don't Upgrade (1) | Failure/Upgrade (2)]
SWVersion [On Failure] = Variable length ASCII text specifying the SWVersion [On Failure] = Variable length ASCII text specifying the
correct software version the AP should have in order to complete the correct software version the AP should have in order to complete the
session registration with the AC. session registration with the AC.
5.2.7 CTP Set-State-Req 5.2.7 CTP_Set-State-Req
This message is sent by the AC to modify the operational state of the This message is sent by the AC to modify the operational state of the
AP. For example, at some point during an established connection it AP. For example, at some point during an established connection it
may be necessary to instruct an AP to go to STANDBY state or initiate may be necessary to instruct an AP to go to STANDBY state or initiate
a reboot/reset of its state machine. These states are usually a reboot/reset of its state machine. These states are usually
entered upon user request entered upon user request
The following states are defined and apply to the AP: The following states are defined and apply to the AP:
ACTIVE ACTIVE
Indication to the AP that it should exit standby state and should Indication to the AP that it should exit standby state and should
resume full active network state including enabling it's RF resume full active network state including enabling its RF
interfaces. This is the default state of the AP after successful interfaces. This is the default state of the AP after successful
configuration phase. configuration phase.
STANDBY STANDBY
This signifies a state where the AP, although connected to the AC, is This signifies a state where the AP, although connected to the AC, is
in a state whereby no RF connection is allowed. It may be a sent to in a state whereby no RF connection is allowed. It may be a sent to
the AP upon user request. the AP upon user request.
RESET RESET
skipping to change at page 18, line 16 skipping to change at page 18, line 29
from the AP. The AC SHOULD detect the loss of connectivity with the from the AP. The AC SHOULD detect the loss of connectivity with the
AP based on the receipt of a Poll-Req message. AP based on the receipt of a Poll-Req message.
HEADER HEADER
Type = 17 Type = 17
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = ID corresponding to the Poll-Req received. REQ ID = ID corresponding to the Poll-Req received.
5.2.11 CTP MU-Connect-Req 5.2.11 CTP_MU-Connect-Req
This message is sent by the AP to relay an association request This message is sent by the AP to relay an association request
received from an MU to the AC. received from an MU to the AC.
HEADER HEADER
Type = 51 Type = 51
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID REQ ID
MU-MAC-Address = MAC Address corresponding to the associating MU MU-MAC-Address = MAC Address corresponding to the associating MU
NETWORK ID = Network identification where association is taking NETWORK ID = Network identification where association is taking
place place
RADIO ID = Radio ID where association is taking place RADIO ID = Radio ID where association is taking place
5.2.12 CTP MU-Connect-Rsp 5.2.12 CTP_MU-Connect-Rsp
This message is sent by the AC to authorize the access point to relay This message is sent by the AC to authorize the access point to relay
an association response to the MU requesting service. If the an association response to the MU requesting service. If the
association is successful, then the AC MAY also include optional association is successful, then the AC MAY also include optional
payloads such as Policy which can be enforced at the AP. payloads such as Policy which can be enforced at the AP.
If the association is rejected by the AC, the AP must disallow If the association is rejected by the AC, the AP must disallow
association of the MU. association of the MU.
HEADER HEADER
Type = 52 Type = 52
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = from the corresponding MU-Connect-Req message REQ ID = from the corresponding MU-Connect-Req message
MU-MAC-Address = MAC Address corresponding to the associating MU MU-MAC-Address = MAC Address corresponding to the associating MU
STATUS = [Success (1) | Failure (2)] STATUS = [Success (1) | Failure internal error (2)| Failure user
deny (3)]
5.2.13 CTP_MU-Disconnect-Req
5.2.13 CTP MU-Disconnect-Req
This message is sent by the AC to request that a specific Mobile Unit This message is sent by the AC to request that a specific Mobile Unit
session be removed from the AP list of currently connected devices. session be removed from the AP list of currently connected devices.
This operation may be the result of Mobile Unit roaming to a This operation may be the result of Mobile Unit roaming to a
different AP or the result of Mobile Unit session timeout, or user different AP or the result of Mobile Unit session timeout, or
request. administrator request.
The MU-MAC-Address identifies the device in question. The MU-MAC-Address identifies the device in question.
HEADER HEADER
Type = 53 Type = 53
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = ID for the request. Must increment after every REQ ID = ID for the request. Must increment after every
retransmission of this message. retransmission of this message.
MU-MAC-Address = MAC Address corresponding to the MU that is to be MU-MAC-Address = MAC Address corresponding to the MU that is to be
disconnected. disconnected.
RADIO ID = Radio ID where disconnection is required. RADIO ID = Radio ID where disconnection is required.
5.2.14 CTP MU-Disconnect-Rsp 5.2.14 CTP_MU-Disconnect-Rsp
This message is sent by the AP to indicate that it has successfully This message is sent by the AP to indicate that it has successfully
processed a disconnect request by the AC. At this point the MU should processed a disconnect request by the AC. At this point the MU should
no longer be associated with the AP. no longer be associated with the AP.
HEADER HEADER
Type = 54 Type = 54
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = Same ID that was received in the MU-Disconnect-Req REQ ID = Same ID that was received in the MU-Disconnect-Req
message. message.
MU-MAC-ADDRESS = MAC Address corresponding to the MU that was MU-MAC-ADDRESS = MAC Address corresponding to the MU that was
disconnected disconnected
STATUS = [Success (1) | Failure (2)] STATUS = [Success (1) | Failure (2)]
5.2.15 CTP MU-Disconnect-Nfy 5.2.15 CTP_MU-Disconnect-Nfy
This message is sent by the AP to the AC to indicate that it has This message is sent by the AP to the AC to indicate that it has
received an explicit disconnection message from the MU. The received an explicit disconnection message from the MU. The
transmission of this message from the AP is dependent on the MAC transmission of this message from the AP is dependent on the MAC
layer of the radio technology implemented on the AP as well as the layer of the radio technology implemented on the AP as well as the
capability of the MU. For example, the radio MAC layer may or may capability of the MU. For example, the radio MAC layer may or may
not support an explicit "disconnect" trigger when an MU goes away. not support an explicit "disconnect" trigger when an MU goes away.
Rather, the disconnection is based on a timer. In cases where the Rather, the disconnection is based on a timer. In cases where the
disconnection is timer based, the AC may be the appropriate entity to disconnection is timer based, the AC may be the appropriate entity to
handle idle timer management. However, in the case where there may handle idle timer management. However, in the case where there may
be a disconnect indication, then the AP must send this message to the be a disconnect indication, then the AP must send this message to the
AC when and MU disconnects. AC when and MU disconnects.
HEADER: HEADER:
Type = 57 Type = 57
SessionID = AP session ID negotiated at registration SessionID = AP session ID negotiated at registration
PAYLOAD PAYLOAD
MU-MAC-Address = MAC address of Mobile unit that was disconnected MU-MAC-Address = MAC address of Mobile unit that was disconnected
NETWORK ID = NETWORK ID =
RADIO ID =
5.2.16 CTP MU-Authenticate-Req 5.2.16 CTP MU-Authenticate-Req
This message is sent by the AP to forward an authentication request This message is sent by the AP to forward an authentication request
to the AC. In the case of 802.1x/EAP authentication, the payload of to the AC. In the case of 802.1x/EAP authentication, the payload of
this packet will include information that the AC will forward to a this packet will include information that the AC will forward to a
RADIUS Server RADIUS Server
HEADER HEADER
Type = 55 Type = 55
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID REQ ID
The authentication request payload between the AP and the AC AUTH_PAYLOAD = The authentication request payload between the AP
carries the request of the MU for authentication. In typical cases and the AC carries the request of the MU for authentication. In
this will be the EAP packets from an 802.1x supplicant. typical cases this will be the EAP packets from an 802.1x supplicant.
5.2.17 CTP MU-Authenticate-Rsp 5.2.17 CTP MU-Authenticate-Rsp
This message is sent by the AC to forward an authentication response This message is sent by the AC to forward an authentication response
to the AP. In the case of 802.1x/EAP authentication, the payload of to the AP. In the case of 802.1x/EAP authentication, the payload of
this packet will include the response from the RADIUS server which this packet will include the response from the RADIUS server which
will be forwarded to the AP. will be forwarded to the AP.
HEADER HEADER
Type = 56 Type = 56
SessionID Ė AP session id from registration SessionID ° AP session id from registration
PAYLOAD PAYLOAD
REQ ID = from the MU-Authenticate-Req message REQ ID = from the MU-Authenticate-Req message
The Authentication response payload between the AP and the AC AUTH_PAYLOAD = The Authentication response payload between the AP
carries the response from the authentication server. In typical and the AC carries the response from the authentication server. In
cases this will be the EAP packets from the Authentication server. typical cases this will be the EAP packets from the Authentication
server.
STATUS = [Success (1) | Failure (2)] - Note that the authenticator STATUS = [Success (1) | Failure (2)] - Note that the authenticator
to authentication server interface resides in the AC so the AC does to authentication server interface resides in the AC so the AC does
know the state of the authentication. know the state of the authentication.
Note: There may be multiple transitions of this message set. Note: There may be multiple transitions of this message set.
5.3 Configuration and Statistics messages 5.3 Configuration and Statistics messages
These messages correspond to information and command exchanges These messages correspond to information and command exchanges
between AP and AC only after between AP and AC only after successful authentication and setup of
the secure channel between AP and AC.
5.3.1 CTP Cap-Req 5.3.1 CTP Cap-Req
This message is sent by the AP to indicate to the AC the capabilities This message is sent by the AP to indicate to the AC the capabilities
of this AP in regards to the number of radios and the types of RF of this AP in regards to the number of radios and the types of RF
technologies that it supports. The AP will encode its capabilities technologies that it supports. The AP will encode its capabilities
per each RADIO (or interface) that it supports. These are encoded in per each RADIO (or interface) that it supports. These are encoded in
a variable length embedded attribute format called "capabilities a variable length embedded attribute format called Űcapabilities
control frames". A type-length-value encoding scheme, similar to the control framesŲ. A type-length-value encoding scheme, similar to the
format of payloads of regular control messages, is used to encode the format of payloads of regular control messages, is used to encode the
capabilities attributes (ATTs) in the capability control frames. capabilities attributes (ATTs) in the capability control frames.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... | Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The available capability attributes are defined as follows: The available capability attributes are defined as follows:
skipping to change at page 22, line 4 skipping to change at page 22, line 21
Length= 3 bytes Length= 3 bytes
Value= radio information type as defined below: Value= radio information type as defined below:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIO-INDEX | RADIO-TYPE | NUM NETWORKS | | RADIO-INDEX | RADIO-TYPE | NUM NETWORKS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where where
RADIO-INDEX is a unique index of the enumeration of the RADIO-INDEX is a unique index of the enumeration of the
number of radios that the AP supports. The AC will use this number of radios that the AP supports. The AC will use this
value for subsequent configuration and control. value for subsequent configuration and control.
RADIO-TYPE is defined as RADIO-TYPE is defined as
o Reserved = 0
o 802.11a = 1 o 802.11a = 1
o 802.11b only = 2 o 802.11b only = 2
o 802.11g only = 3 o 802.11g only = 3
o 802.11b and g = 4 o 802.11b and g = 4
o 802.11n = 5 o 802.11n = 5
o 802.15 = 6 o 802.15.1 = 6
o 802.16 = 7 o 802.15.3 = 7
o 802.20 = 8 o 802.15.4 = 8
o 802.20 = 9
o 802.22 = 10
o Reserved = 11 through 254
o All = 255 (this value indicates that o All = 255 (this value indicates that
all interfaces are configurable all interfaces are configurable
to any radio type) to any radio type)
NUM-NETWORKS is the number of unique networks that each NUM-NETWORKS is the number of unique networks that each
RADIO supports. RADIO supports.
3) ATT-NETWORK-INFO - This attribute consists of the unique 3) ATT-MAC-INFO ° This attribute consists of information
pertaining to the implementation of the wireless MAC
layer in the WTP. This in turn specifies to the AC the
expected data type that will be received. At this time
only two types of MAC implementation are supported, ie.
Local MAC and Split MAC.
Type= 3
Length= 2 bytes
Value= MAC layer information as defined below:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIO-INDEX | MAC-TYPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
RADIO-INDEX is a unique index of the enumeration of the
number of radios that the AP supports
MAC-TYPE is defined as
o Local MAC = 1
o Split MAC = 2
4) ATT-NETWORK-INFO - This attribute consists of the unique
information that identifies each network per RADIO-INDEX information that identifies each network per RADIO-INDEX
and consists of RADIO-INDEX, NETWORK-INDEX and NETWORK- and consists of RADIO-INDEX, NETWORK-INDEX and NETWORK-
ID. Each Cap-Req payload MUST contain exactly NUM- ID. Each Cap-Req payload MUST contain exactly NUM-
NETWORKS worth of unique ATT-NETWORK-INFO attributes. NETWORKS worth of unique ATT-NETWORK-INFO attributes.
Type= 3 Type= 4
Length= 8 bytes Length= 8 bytes
Value= network information type as defined below: Value= network information type as defined below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIO-INDEX | NETWORK-INDEX | NETWORK ID | | RADIO-INDEX | NETWORK-INDEX | NETWORK ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NETWORK ID | | NETWORK ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 50 skipping to change at page 24, line 4
| NETWORK ID | | NETWORK ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where where
RADIO-INDEX is a unique index of the enumeration of the RADIO-INDEX is a unique index of the enumeration of the
number of radios that the AP supports number of radios that the AP supports
NETWORK-INDEX is a unique index of the enumeration of the NETWORK-INDEX is a unique index of the enumeration of the
networks that each RADIO supports networks that each RADIO supports
NETWORD-ID is the unique identifier for the network. This 6 NETWORD-ID is the unique identifier for the network. This 6
byte value MAY be the MAC address for the given network byte value MAY be the MAC address for the given network
within the radio. In the case of 802.11 radios, this value within the radio. In the case of 802.11 radios, this value
SHOULD be the BSS ID. SHOULD be the BSS ID.
4) ATT-VENDOR-ID - name of vendor or manufacturer of AP. 5) ATT-VENDOR-ID - name of vendor or manufacturer of AP.
Type= 4 Type= 5
Length= 4 bytes Length= 4 bytes
Value = a 32-bit value containing the IANA assigned Value = a 32-bit value containing the IANA assigned
"SMI Network Management Private Enterprise Codes" [3]. "SMI Network Management Private Enterprise Codes" [3].
5) ATT-PRODUCT-ID - name of product. 6) ATT-PRODUCT-ID - name of product.
Type= 5 Type= 6
Length= variable length value of string Length= variable length value of string
Value= ASCII string for the name of the product, non- Value= ASCII string for the name of the product, non-
Null terminated. Null terminated.
HEADER HEADER
Type = 20 Type = 20
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = increments with each retransmission. REQ ID = increments with each retransmission.
skipping to change at page 23, line 43 skipping to change at page 24, line 45
element that it received in the Cap-Req message. This is element that it received in the Cap-Req message. This is
accomplished by sending back exactly ATT-NUM-RADIOS worth of ATT- accomplished by sending back exactly ATT-NUM-RADIOS worth of ATT-
RADIO-INFO-ACK for each RADIO-INFO sub-attribute that this AC RADIO-INFO-ACK for each RADIO-INFO sub-attribute that this AC
supports. supports.
The ATT-RADIO-INFO-ACK is an attribute that contains the RADIO-INDEX The ATT-RADIO-INFO-ACK is an attribute that contains the RADIO-INDEX
and CAP-STATUS sub-attribute. For each Radio type that the AC and CAP-STATUS sub-attribute. For each Radio type that the AC
supports, the CAP-STATUS must be set to 1. For each radio type that supports, the CAP-STATUS must be set to 1. For each radio type that
the AC does not support, the CAP-STATUS must be set to 0. the AC does not support, the CAP-STATUS must be set to 0.
Type= 6 Type= 7
Length= 2 bytes Length= 2 bytes
Value= as defined below. Value= as defined below.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIO-INDEX | CAP-STATUS | | RADIO-INDEX | CAP-STATUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HEADER HEADER
Type = 21 Type = 21
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
REQ ID = ID corresponding to the Cap-Req message. REQ ID = ID corresponding to the Cap-Req message.
The AC capabilities attribute response encoded as TLVs and as The AC capabilities attribute response encoded as TLVs and as
defined above. defined above.
5.3.3 CTP Config-Req 5.3.3 CTP Config-Req
skipping to change at page 24, line 18 skipping to change at page 25, line 20
PAYLOAD PAYLOAD
REQ ID = ID corresponding to the Cap-Req message. REQ ID = ID corresponding to the Cap-Req message.
The AC capabilities attribute response encoded as TLVs and as The AC capabilities attribute response encoded as TLVs and as
defined above. defined above.
5.3.3 CTP Config-Req 5.3.3 CTP Config-Req
This message is sent by the AP to request configuration from its This message is sent by the AP to request configuration from its
master AC. This message must be sent only after a receipt of a master AC. This message must be sent only after a receipt of a
successful Auth-Rsp message from the AC and the verification of the successful Auth-Rsp message from the AC and the verification of the
AC's AC REG RESPONSE payload. ACs AC REG RESPONSE payload.
HEADER HEADER
Type = 8 Type = 8
SessionID - the assigned ID as received in the Auth-Rsp message. SessionID ° the assigned ID as received in the Auth-Rsp message.
PAYLOAD PAYLOAD
REQ ID REQ ID
No specific information is required on this message. No specific information is required on this message.
5.3.4 CTP Config-Rsp 5.3.4 CTP Config-Rsp
This message is sent by the AC as a response to a Config-Req message This message is sent by the AC as a response to a Config-Req message
to provide the configuration parameters for the registered AP. to provide the configuration parameters for the registered AP.
skipping to change at page 25, line 12 skipping to change at page 26, line 14
updates that require more than one payload for full receipt of updates that require more than one payload for full receipt of
configuration information. configuration information.
HEADER HEADER
Type = 10 Type = 10
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
None None
5.3.6 CTP Config-Status-Notify 5.3.6 CTP_Config-Status-Notify
This message is used by the AP to indicate to the AC that it has This message is used by the AP to indicate to the AC that it has
successfully completed it's configuration as per parameters indicated successfully completed it's configuration as per parameters indicated
by the AP. by the AP.
HEADER HEADER
Type = 11 Type = 11
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
STATUS STATUS
5.3.7 CTP Stats-Notify 5.3.7 CTP_Stats-Notify
This message is sent by the AP to provide periodic operational This message is sent by the AP to provide periodic operational
statistics to the AC. This message is also used following a correct statistics to the AC. This message is also used following a correct
configuration establishment to indicate to the AC that the AP is configuration establishment to indicate to the AC that the AP is
functionally ready to enter ACTIVE state. functionally ready to enter ACTIVE state.
HEADER HEADER
Type = 14 Type = 14
SessionID = AP session id from registration SessionID = AP session id from registration
skipping to change at page 25, line 50 skipping to change at page 27, line 4
5.3.8 CTP Stats-Req 5.3.8 CTP Stats-Req
This message is sent by the AC to request statistics information upon This message is sent by the AC to request statistics information upon
request. It is intended to be used as an interface by an request. It is intended to be used as an interface by an
administrator or management application to query the AP for administrator or management application to query the AP for
instantaneous statistics information. instantaneous statistics information.
HEADER HEADER
Type = 18 Type = 18
SessionID = AP session id from registration SessionID = AP session id from registration
PAYLOAD PAYLOAD
None STATS = The type of the statistics payload is defined in Section
5.3.10
5.3.9 CTP Stats-Rsp 5.3.9 CTP Stats-Rsp
This message is sent by the AP to provide operational statistics to This message is sent by the AP to provide operational statistics to
the AC as per the Stats-Req message. It is similar in format to the the AC as per the Stats-Req message. It is similar in format to the
Stats-Notify message. Stats-Notify message.
HEADER HEADER
Type = 19 Type = 19
SessionID = AP session id from registration SessionID = AP session id from registration
skipping to change at page 26, line 29 skipping to change at page 27, line 32
5.3.10 Configuration and Statistics 5.3.10 Configuration and Statistics
Two data representations were considered for the CTP configuration Two data representations were considered for the CTP configuration
and statistics payload. The first data representation considered was and statistics payload. The first data representation considered was
a TLV representation where all the variables for the statistics and a TLV representation where all the variables for the statistics and
configuration would be defined as groups of TLVs. Given the nature of configuration would be defined as groups of TLVs. Given the nature of
CTP as a radio agnostic protocol and the complexity of the statistics CTP as a radio agnostic protocol and the complexity of the statistics
and configuration of the 802.11 protocols with multiple networks per and configuration of the 802.11 protocols with multiple networks per
radio a TLV representation might be cumbersome and not extensible. radio a TLV representation might be cumbersome and not extensible.
Most of today's network devices in both the enterprise and the Most of todays network devices in both the enterprise and the
carrier space employ the Simple Network Management Protocol. Thus, it carrier space employ the Simple Network Management Protocol. Thus, it
is natural to assume that most, if not all, APs will contain an is natural to assume that most, if not all, APs will contain an
embedded SNMP agent able to decode SMI representations. Using SMI embedded SNMP agent able to decode SMI representations. Using SMI
representations for configuration and statistics variables can speed representations for configuration and statistics variables can speed
up deployment of CTP without incurring additional cost for the APs. up deployment of CTP without incurring additional cost for the APs.
Our recommendation is to reuse the 802.11 MIBs where applicable for Our recommendation is to reuse the 802.11 MIBs where applicable for
the CTP configuration and statistics message payload. MIB extensions the CTP configuration and statistics message payload. MIB extensions
should be defined where the corresponding IEEE MIBs are not should be defined where the corresponding IEEE MIBs are not
sufficient. Upon reception of the message the CTP daemon should sufficient. Upon reception of the message the CTP daemon should
forward the configuration and statistics message payload to the SNMP forward the configuration and statistics message payload to the SNMP
daemon for further decoding and processing of the SMI O.I.D.s. daemon for further decoding and processing of the SMI O.I.D.s.
5.4 CTP Data Messages 5.4 CTP_Data Messages
The CTP data messages use the same CTP header as the control and The CTP data messages use the same CTP header as the control and
other messages. If the Type field is 15 (CTP-Data), then the Policy other messages. If the Type field is 15 (CTP-Data), then the Policy
field of the header is used by the AC to tag the data for special field of the header is used by the AC to tag the data for special
handling. The interpretation of the Policy field is left up to the handling. The interpretation of the Policy field is left up to the
implementation. An example of its use is as follows: implementation. An example of its use is as follows:
Data packet coming into the AC from the wired network is a voice Data packet coming into the AC from the wired network is a voice
packet as indicated by the TOS or DSCP markings in the IP header. packet as indicated by the TOS or DSCP markings in the IP header.
This TOS/DSCP byte will be copied to the outer transport header for This TOS/DSCP byte will be copied to the outer transport header for
proper priority handling within the network between the AP and the proper priority handling within the network between the AP and the
AC. However, for appropriate classification at the AP, the AC sets AC. However, for appropriate classification at the AP, the AC sets
the Policy field to a value that allows the AP to prioritize this the Policy field to a value that allows the AP to prioritize this
packet over other data packets that may have a lower priority. packet over other data packets that may have a lower priority.
Similarly in the reverse direction, the MU may have set the Similarly in the reverse direction, the MU may have set the
appropriate fields in the original IP header, but the AP can appropriate fields in the original IP header, but the AP can
interpret those bits and map them to the Policy field in the CTP-Data interpret those bits and map them to the Policy field in the CTP-Data
header for special dispensation at the AC. header for special dispensation at the AC.
5.4.1 CTP Data 5.4.1 CTP_Data
This message is utilized as the transport of MU layer data. The This message is utilized as the transport of MU layer data. The
contents of the message body are not interpreted by the AP layer contents of the message body are not interpreted by the AP layer
other than sending it to the MAC layer of the AP. other than sending it to the MAC layer of the AP.
HEADER HEADER
Type = 15 Type = 15
SessionID = AP session id from registration SessionID = AP session id from registration
Policy = as set by the implementation Policy = as set by the implementation
skipping to change at page 29, line 25 skipping to change at page 30, line 25
Once confirmation of successful registration is received the device Once confirmation of successful registration is received the device
now has a properly established communications/tunneling session with now has a properly established communications/tunneling session with
the AC. The Authentication response MUST have indicated a valid CTP the AC. The Authentication response MUST have indicated a valid CTP
session ID by which this tunnel is registered on the AC. So in this session ID by which this tunnel is registered on the AC. So in this
state, the SessionId MUST be non-zero. state, the SessionId MUST be non-zero.
This state persists until device terminates or communications with This state persists until device terminates or communications with
the AC are interrupted. To assist in the detection of connection the AC are interrupted. To assist in the detection of connection
termination, the device MUST implement the CTP Poll-Req and Poll-Rsp termination, the device MUST implement the CTP Poll-Req and Poll-Rsp
messages as described previously. Another method of exiting this messages as described previously. Another method of exiting this
state is with an explicit Set-State message that may be only be state is with an explicit Set-State message that may only be
initiated by the AC to the AP. initiated by the AC to the AP.
6.4 Standby State 6.4 Standby State
At some time during the operation, it may be necessary to instruct an At some time during the operation, it may be necessary to instruct an
AP to halt its current operation, ie. to switch off the RF AP to halt its current operation, ie. to switch off the RF
interface(s) on the AP . This is done by the Set-State message. The interface(s) on the AP . This is done by the Set-State message. The
device will remain in this state, until explicitly told by the AC to device will remain in this state, until explicitly told by the AC to
resume operation also using the Set-State message. resume operation also using the Set-State message.
7. Security Considerations 7. Authentication, Encryption and Session Key generation
Since the AP and AC can be separated over any arbitrary L3 cloud, Since the AP and AC can be separated over any arbitrary L3 cloud,
first and foremost there is a need for a secure binding between the first and foremost there is a need for a secure binding between the
AC and AP. A control channel security association is required AC and AP. A control channel security association is required
between the AC and AP. The AC and AP must go through a mutual between the AC and AP.
authentication phase during a registration and authentication process
and form a security association. A couple of assumptions are made to 7.1 Authentication
ensure this security association is created. First, there must be a
secure mechanism to get the digital certificates onto the APs and ACs The AC and AP must go through a mutual authentication phase during a
and that process must be run either at the factory or prior to device registration and authentication process and form a security
association. A couple of assumptions are made to ensure this
security association is created. First, there must be a secure
mechanism to get the digital certificates onto the APs and ACs and
that process must be run either at the factory or prior to device
deployment. Secondly, the placement of the AP ID (in most cases the deployment. Secondly, the placement of the AP ID (in most cases the
AP serial number) in a data store on the AC assumes a secure AP serial number) in a data store on the AC assumes a secure
insertion mechanism. This may be a manual process or other secure ID insertion mechanism. This may be a manual process or other secure ID
provisioning methods may be employed. Once the registration and provisioning methods may be employed. Mutual authentication of AP and
authentication process has successfully completed then the control AC is done by means of digital certificates as is described below.
traffic is encrypted. The traffic is confined to control,
configuration and management traffic between the AC and AP.
There is an optional data path security association that can also be
created. It is believed that for security sensitive applications and
deployments there will always be an end to end encrypted tunnel of MU
data traffic. Therefore, a data path encryption mechanism is
considered optional and configurable based on security policy.
STA authentication and security policy enforcement is done centrally
in the AC but the mechanisms are out of scope for this protocol.
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Yang, L., et. al., "CAPWAP Problem Statement", February 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-
statement-00.txt>.
[3] "Assigned Numbers: RFC 1700 is Replaced by an On-line Database",
January 2002, <ftp://ftp.isi.edu/in-notes/rfc3232>.
[4] Eastlake, D., et. al., "Randomness Recommendations for
Security", December 1994, RFC 1750.
[5] Whiting, et al., "Counter with CBC-MAC (CCM)", September 2003,
RFC 3610.
9. Author's Addresses
Paulo Francisco
Chantry Networks
1900 Minnesota Court
Mississauga, ON M8V 1E5
Canada
Phone: +1 905-567-6900
Email: paulo@chantrynetworks.com
Inderpreet Singh
Chantry Networks
1900 Minnesota Court
Mississauga, ON M8V 1E5
Canada
Phone: +1 905-567-6900
Email: isingh@chantrynetworks.com
Floyd Backes
Propagate Networks
125 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-264-4884
Email: fbackes@propagatenet.com
10. Appendix I - Registration and Authentication
The registration and authentication phase of CTP is detailed below.
+----+ +----+ +----+ +----+
| AP | | AC | | AP | | AC |
+----+ +----+ +----+ +----+
Reg-Req(AP-ID) Reg-Req(AP-ID)
----------------------------------------------> ---------------------------------------------->
Reg-Rsp(Status,AP-challenge) Reg-Rsp(Status,AP-challenge)
<---------------------------------------------- <----------------------------------------------
skipping to change at page 31, line 50 skipping to change at page 31, line 36
Reg-Rsp message if there is a match in its data store for the given Reg-Rsp message if there is a match in its data store for the given
AP-ID AP-ID
AP-challenge - is a 16 byte random number generated using [4] as AP-challenge - is a 16 byte random number generated using [4] as
guidelines for the randomness of the challenge. guidelines for the randomness of the challenge.
AP-cert - Is a digital certificate assumed to be available on the AP AP-cert - Is a digital certificate assumed to be available on the AP
prior to its Registration request. The mechanism to get the prior to its Registration request. The mechanism to get the
certificate onto the AP is out of scope for this document. certificate onto the AP is out of scope for this document.
AP-resp - Is a digital signature over the MD5 hash of the AP- AP-resp - Is a digital signature over the SHA-1 hash of the AP-
challenge concatenated with the AP-ID. challenge concatenated with the AP-ID.
S-ap(H-sha1(AP-challenge|AP-ID))
S-ap(H-md5(AP-challenge|AP-ID))
AP-challenge - is a 16 byte random number generated for subsequent AP-challenge - is a 16 byte random number generated for subsequent
authentication of the AC. authentication of the AC.
AC-cert - Is a digital certificate of the AC that is assumed to be AC-cert - Is a digital certificate or chain of certificates of the AC
available on the AC prior to sending the Reg-Rsp message. The that is assumed to be available on the AC prior to sending the Reg-
mechanism to get the certificate onto the AC is out of scope for this Rsp message. The mechanism to get the certificate or chain of
document. certificates onto the AC is out of scope for this document.
AC-resp - is a digital signature over the MD5 hash of the AC- AC-resp - is a digital signature over the SHA-1 hash of the AC-
challenge concatenated with the encrypted session key. challenge concatenated with the encrypted session key.
S-ac(H-md5(AC-challenge|Enc-ac-p(SessionKey))) S-ac(H-sha1(AC-challenge|Enc-ac-p(SessionKey)))
Session Key - is actually the encrypted randomly generated session Session Key - is actually the encrypted randomly generated session
encryption keying material. The AC uses the public key of the AP to encryption keying material. The AC uses the public key of the AP to
encrypted the session encryption key.[Key generation algorithm is encrypt the session encryption key. The size of the Session Key is 19
TBD] bytes. The first 16 bytes are used as AES-CCM encryption and the
remaining 3 bytes are used as a salt for a nonce which is required by
the AES-CCM algorithm. See section 7.2 for encryption details.
The Session key is a random number generated using [4]. At the time
of writing this document there are no known weak keys for AES.
1. The AP sends a Reg-Req message with its AP SERIAL NUMBER. If The following steps describe in detail the registration and
it does not receive a Reg-Req within 3 seconds, it must resend authentication process:
the Reg-Req message.
2. Upon receipt of the Reg-Req message, the AC checks its data 1. The AP sends a Reg-Req message with its AP SERIAL NUMBER. If it
store for the AP SERIAL NUMBER. If it exists then the AC does not receive a Reg-Req within 3 seconds, it must resend the
sends back a Reg-Rsp message with STATUS payload with Success Reg-Req message.
(1) attribute and an AP CHALLENGE payload. If the AP SERIAL 2. Upon receipt of the Reg-Req message, the AC checks its data store
NUMBER does not exist, then a Reg-Rsp message with a STATUS for the AP SERIAL NUMBER. If it exists then the AC sends back a
payload of Failure (2) is sent back. Reg-Rsp message with STATUS payload with Success (1) attribute
and an AP CHALLENGE payload. If the AP SERIAL NUMBER does not
exist, then a Reg-Rsp message with a STATUS payload of Failure
(2) is sent back.
3. The AP will take the AP CHALLENGE payload, concatenate it with 3. The AP will take the AP CHALLENGE payload, concatenate it with
the AP SERIAL NUMBER and calculate an AP RESPONSE as shown the AP SERIAL NUMBER and calculate an AP RESPONSE as shown above
above and send it back to the AC along with an AC CHALLENGE and send it back to the AC along with an AC CHALLENGE payload and
payload and its own digital CERTIFICATE payload in an Auth-Req its own digital CERTIFICATE payload in an Auth-Req message.
message.
4. Upon receipt of the Auth-Req message the AC will 4. Upon receipt of the Auth-Req message the AC will
a. Verify the AP's digital certificate a. Verify the AP's digital certificate
b. Verify the AP RESPONSE, which was the digital signature of b. Verify the AP RESPONSE, which was the digital signature of
the AP over the hash of the AP CHALLENGE and the AP SERIAL the AP over the hash of the AP CHALLENGE and the AP SERIAL
NUMBER. This is done with the public key of the AP. NUMBER. This is done with the public key of the AP.
c. If both a) and b) are verified correctly, then the STATUS c. If both a) and b) are verified correctly, then the STATUS
payload will contain Success (1). Otherwise it will payload will contain Success (1). Otherwise it will contain
contain Failure (2). Failure (2).
d. If Success, then the AC will add its own CERTIFICATE to d. If Success, then the AC will add its own CERTIFICATE to the
the Auth-Rsp message Auth-Rsp message
e. Encrypt the session encryption keys with the public key of e. Encrypt the session encryption keys with the public key of
the AP. the AP.
f. Generate a unique SessionID to be used in subsequent CTP f. Generate a unique SessionID to be used in subsequent CTP
messages. messages.
g. Send back an Auth-Rsp message with STATUS, CERTIFICATE, AC g. Send back an Auth-Rsp message with STATUS, CERTIFICATE, AC
RESPONSE and SESSION KEY payloads with the SessionID in RESPONSE and SESSION KEY payloads with the SessionID in the
the CTP header. CTP header.
5. Upon receipt of the Auth-Rsp message, the AP will 5. Upon receipt of the Auth-Rsp message, the AP will
a. Verify the AC's digital certificate a. Verify the AC's digital certificate
b. Verify the AC RESPONSE which was the digital signature of b. Verify the AC RESPONSE which was the digital signature of the
the AC over the hash of the AC CHALLENGE and the encrypted AC over the hash of the AC CHALLENGE and the encrypted
session encryption key. session encryption key.
c. Decrypt the encrypted session encryption key with its own c. Decrypt the encrypted session encryption key with its own
private key private key
d. Store the SessionID which will be used in each subsequent d. Store the SessionID which will be used in each subsequent CTP
CTP message. message.
6. All CTP control messages after the Auth-Rsp will be sent with 6. All CTP control messages after the Auth-Rsp will be sent
TBD encryption and per packet authentication mechanism. encrypted with AES-CCM as described in section 7.2.
(Current recommended scheme is AES-CCM as per [5].)
TBW - Rekeying mechanism 7.2 Encryption
Once the registration and authentication process has successfully
completed then the control traffic is encrypted. The traffic is
confined to control, configuration and management traffic between the
AC and AP.
It is believed that for security sensitive applications and
deployments there will always be an end to end encrypted tunnel for
MU data traffic. Therefore, a data path encryption mechanism is not
provided by CTP.
All control messages except of CTP_Reg-Req, CTP_Reg-Rsp, CTP_Auth-Req
and CTP_Auth-Rsp, which are used to establish a trust relationship
between the AP and AC, must be encrypted. If a non-encrypted CTP
control packet with type other than CTP_Reg-Req, CTP_Reg-Rsp,
CTP_Auth-Req and CTP_Auth-Rsp is received, it MUST be dropped by a
receiver and no notification is sent to the sender.
Encrypted packets MUST be sent in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |0|0|0|P|E| Type | Policy | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Id. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV (8 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted data |
| (var length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 8 bytes is general CTP header described in section 4.1. E
bit MUST be equal to 1.
The additional fields have the following meaning:
IV ° Initialization Vector used by AES-CCM as described in section
7.2.
Sequence Number ° 32 bits value used for anti-replay protection.
Encrypted Data ° data of variable length encrypted with AES-CCM.
Typically the encrypted data corresponds to the specified message
payloads.
Authentication Data ° MAC of CTP header, IV, Sequence Number and
encrypted data.
CTP uses AES-CCM encryption as defined in [5] with value L = 4 and
value M = 8. The Nonce length is 11 bytes. The Nonce is formed by
concatenation of 3 bytes of the salt send by AC to the AP during
Session Key exchange and 8 bytes of Initialization Vector. The sender
of a packets MUST NOT send two packets with the same IV, as it
immediately leads to plain-text revealing.
The Sequence Number field MUST start from zero for the first
encrypted packet and is incremented each time a packet is encrypted.
The receiver MUST use the sequence number field to protect against
replay-attack and MAY use it to accept reordered or late packets. The
sender MUST negotiate a new session key before reaching maximum value
for the Sequence Number.
The sender of an encrypted packet MUST perform the following steps
during the packet encryption:
- IV and the Sequence Number are inserted into the packet after CTP
header.
- E bit in CTP header is set to 1.
- The first 20 bytes including CTP header, IV and the Sequence
Number are passed to AES-CCM for authentication only.
- The CTP payload is encrypted with AES-CCM.
- After encryption, a MAC value received from AES-CCM is copied to
the output packet after encrypted data.
- The Sequence Number MUST be incremented
- IV value must be changed to another value which has not been used
so far with the current encryption key.
The receiver of the encrypted packet MUST perform the following steps
during the packet decryption:
- E bit in CTP header is checked. If it is not 1, the packet is
silently dropped.
- Type of the packet is checked. All control packets except CTP_Reg-
Req, CTP_Reg-Rsp, CTP_Auth-Req and CTP_Auth-Rsp must be encrypted.
- The Sequence Number is compared to the sequence number of the last
received packet, which MUST be stored by the receiver. If the
Sequence Number is larger that the one stored by the receiver the
packet MUST be accepted for further processing. If the sequence
number is equal to the one stored by the receiver the packet MUST
be silently dropped. If the sequence number is lower that stored by
the receiver, packet MAY be accepted it the receiver implements
sliding window algorithm.
- Payload of the packet is passed for decryption to AES-CCM
algorithm.
- The first 20 bytes of the packet starting with CTP header are
passed to AES-CCM for authentication.
- Data payload is passed to AES-CCM for decryption
- After decryption, MAC value received from AES-CCM decryption
process is compared to the MAC value received in the packet. If
locally calculated MAC does not match the MAC value from the
received packet, the packet MUST be silently dropped. If MAC values
are equal, the packet is passed for further processing.
- IV, the Sequence Number and MAC values are stripped from the
packet.
- If the Sequence Number from the received packet is larger than
stored by the receiver, the receiver must update the stored
sequence number with the received one.
7.3 Session Key refresh and generation
One session key is used to encrypt control packets exchanged in both
directions between the AP and the AC. The Session Key is always
generated by the AC and is sent to AP during the CTP registration and
authentication phase as described in section 7.1.
The Session Key must be refreshed before either one of the following
happens:
- key lifetime expires
- sequence numbers are exhausted
The Session Key∆s lifetime is not negotiated in-band and is set to 24
hours.
If the Session Key∆s lifetime has expired or the sequence numbers has
been exhausted and the new Session Key has not been negotiated, the
receiver MUST silently drop any received packet and the sender MUST
NOT encrypt CTP packet.
The Key refresh is always initiated by the AP. The packet exchange
between the AP and the AC for new key is TBD.
The AC MAY request the AP to start the key refresh process by sending
TBD packet.
After the Session Key refresh, the AC must use the old key until it
receives a packet encrypted with the new Session Key, what is an
indication that the AP received and accepted the new Session Key.
8. Security considerations
CTP provides mutual authentication of the AP and the AC. The trust is
achieved by digital certificates. The trust hierarchy leading to
successful certificate or certificates chain validation is out of
scope of this document.
Certificates issued for the AP and the AC are bound to the serial
number of the AP and the AC respectively.
During the authentication exchange, the receiver cannot verify that
the sender of the certificate really has the serial number presented
in the certificate. An attacker may steal the legitimate credentials
and send a valid certificate from a device with different serial
number.
During the authentication phase the receiver MAY verify whether the
presented certificate has not been revoked. The mechanism of
accessing CRL is not defined by CTP.
CTP encryption and authentication is sufficient for control packets
only. It MUST NOT be used for data encryption, because the exchange
between the AP and the AC does not use ephemeral keys. Compromise of
AP∆s private key enables an attacker to decrypt all session keys used
in the past between the AP and AC and decrypt all data packets
exchanged between AP and AC.
Control packets exchanged between the AP and the AC are encrypted and
authenticated. Both, confidentiality and authentication is provided
by AES-CCM as described in [5].
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] O∆Hara, B., et. al, ŰCAPWAP Problem StatementŲ, RFC 3990,
February 2005
[3] "Assigned Numbers: RFC 1700 is Replaced by an On-line Database",
January 2002, ftp://ftp.isi.edu/in-notes/rfc3232
[4] Eastlake, D., et. al., "Randomness Recommendations for Security",
December 1994, RFC 1750
[5] Whiting, et al., "Counter with CBC-MAC (CCM)", September 2003,
RFC 3610
10. Author's Addresses
Paulo Francisco
Chantry Networks
1900 Minnesota Court
Mississauga, ON M8V 1E5
Canada
Phone: +1 905-363-6410
Email: paulo@chantrynetworks.com
Inderpreet Singh
Chantry Networks
1900 Minnesota Court
Mississauga, ON M8V 1E5
Canada
Phone: +1 905-363-6412
Email: isingh@chantrynetworks.com
Krzysztof Pakulski
Chantry Networks
1900 Minnesota Court
Mississauga, ON M8V 1E5
Canada
Phone: +1 905-363-6400 (ext. 6449)
Email: kpakulski@chantrynetworks.com
Floyd Backes
AutoCell Laboratories
125 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-264-4884
Email: fbackes@autocell.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it ŰAS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/