CAPWAP Working Group P. Narasimhan
Internet-Draft Aruba Networks
Expires: October 2, 2005 D. Harkins
Trapeze Networks
March 31, 2005
SLAPP : Secure Light Access Point Protocol
draft-narasimhan-ietf-slapp-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The CAPWAP problem statement [3] describes a problem that needs to be
addressed before a wireless LAN (WLAN) network designer can construct
a solution composed of Wireless Termination Points (WTP) and Access
Controllers (AC) from multiple, different vendors. One of the
primary goals is to find a solution that solves the interoperability
Narasimhan & Harkins Expires October 2, 2005 [Page 1]
Internet-Draft SLAPP March 2005
between the two classes of devices (WTPs and ACs) which then enables
an AC from one vendor to control and manage a WTP from another.
The interoperability problem is more general than as stated in the
CAPWAP problem statement [3] because it can arise out of other
networks that do not necessarily involve WLAN or any wireless
devices. A similar problem exists in any network that is composed of
network elements that are managed by a centralized controller where
these two classes of devices are from different vendors and need to
interoperate with each other such that the network elements can be
controlled and managed by the controller.
A possible solution to this problem is to split it into two parts -
one that is technology or application independent which serves as a
common framework across multiple underlying technologies, and another
that is dependent on the underlying technology that is being used in
the network. For example, methods and parameters used by an 802.11
AC to configure and manage a network of 802.11 WTPs are expected to
be quite different than that used by an equivalent 802.16 controller
to manage a network of 802.16 base stations. The architectural
choices for these two underlying technologies may also be
significantly different.
In this draft, we present a protocol that forms the common
technology-independent framework and the ability to add, on top of
this framework, extensions that contain a technology-dependent
component to arrive at a complete solution. We have also presented
one such extension, the image download protocol, in this draft.
Even though the text in this draft is written to specifically address
the problem stated in [3], the solution can be applied to any problem
that has a controller (equivalent to the AC) managing one or more
network elements (equivalent to the WTP).
Narasimhan & Harkins Expires October 2, 2005 [Page 2]
Internet-Draft SLAPP March 2005
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Conventions used in this document . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Protocol Description . . . . . . . . . . . . . . . . . . . 9
4.1.1 State Machine Explanation . . . . . . . . . . . . . . 9
4.2 Format of a SLAPP Header . . . . . . . . . . . . . . . . . 10
4.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Retransmission . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.1 SLAPP Discover Request . . . . . . . . . . . . . . . . 13
4.5.2 SLAPP Discover Response . . . . . . . . . . . . . . . 15
4.6 SLAPP Discovery Process . . . . . . . . . . . . . . . . . 17
4.6.1 WTP . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.2 AC . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Security Association . . . . . . . . . . . . . . . . . . . . . 20
5.1 Example Authentication Models (Informative) . . . . . . . 20
5.1.1 Mutual Authentication . . . . . . . . . . . . . . . . 21
5.1.2 WTP-only Authentication . . . . . . . . . . . . . . . 21
5.1.3 Anonymous Authentication . . . . . . . . . . . . . . . 21
6. Image Download Protocol . . . . . . . . . . . . . . . . . . . 22
6.1 Image Download Packet . . . . . . . . . . . . . . . . . . 22
6.2 Image Download Request . . . . . . . . . . . . . . . . . . 23
6.3 Image Download Process . . . . . . . . . . . . . . . . . . 23
6.4 Image Download State Machine . . . . . . . . . . . . . . . 24
6.4.1 AC . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4.2 WTP . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Extensibility to other technologies . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
Narasimhan & Harkins Expires October 2, 2005 [Page 3]
Internet-Draft SLAPP March 2005
1. Definitions
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Narasimhan & Harkins Expires October 2, 2005 [Page 4]
Internet-Draft SLAPP March 2005
2. Introduction
The need for a protocol by which wireless LAN (WLAN) Access
Controllers (AC) can control and manage Wireless Termination Points
(WTP) from a different vendor has been presented in the CAPWAP
problem statement [3]. We believe that this problem is more general
than as stated in [3] and can be found in any application, including
non-wireless ones, that requires a central controller to control and
manage one or more network elements from a different vendor.
One way to solve the CAPWAP problem is to define a complete control
protocol that enables an AC from one vendor to control and manage a
WTP from a different vendor. But a solution that is primarily
focused towards solving the problem for one particular underlying
technology (IEEE 802.11, in this case) may find it difficult to
address other underlying technologies. Different underlying
technologies may differ on the set of configuratble options, and
different architectural choices that are specific to that underlying
technology (similar to the local MAC vs. split MAC architectures in
802.11). The architectural choices that are good for one underlying
technology may not necessarily work for another. Not to forget that
there may be multiple architectural choices [2] even for the same
underlying technology. A monolithic control protocol that strives to
solve this problem for multiple technologies runs the risk of adding
too much complexity and not realizing the desired goals, or it runs
the risk of being too rigid and hampering technological innovation.
A different way to solve this problem is to split the solution space
into two components - one that is technology agnostic or independent,
and another that is specific to the underlying technology or even
different approaches for the same underlying technology. The
technology-independent component would be a common framework that
would be an important component of the solution to this class of
problems without any dependency on the underlying technology (i.e.
802.11, 802.16, etc.) being used. The technology-specific component
would be an extension over this common framework and can be easily
defined to be relevant to that technology without the need for having
any dependency on other underlying technologies. This approach also
lends itself easily to extend the protocol as new technologies arise
or as new innovative methods to solve the same problem for an
existing technology present themselves later in the future.
In this draft, we present secure light access point protocol (SLAPP),
a technology-independent protocol by which network elements that are
meant to be centrally managed by a controller can discover one or
more controllers, perform a security association with one of them,
and negotiate an extension that they would use to perform the
technology-specific components of the control and provisioning
Narasimhan & Harkins Expires October 2, 2005 [Page 5]
Internet-Draft SLAPP March 2005
protocol. We have also presented one possible extension that is very
generic and can be applied to any underlying technology.
Figure 1 shows the model by which extensions can be added to SLAPP to
complete a solution for a certain underlying technology. The figure
shows an extension each for 802.11 and 802.16 technology components,
but the SLAPP model does not preclude multiple extensions within a
certain technology segment. For example, a certain SLAPP extension
may choose to support only the local MAC architecture [2] while
deciding not to support the split MAC architecture [2]. While the
image download protocol is presented in this draft, a SLAPP
implementation MUST NOT assume that this extension is supported by
other SLAPP implementations.
+-----------+ +------------+ +------------+
| | | | | |
| Image | | 802.11 | | 802.16 |
| Download | | control | | control | ........
| Extension | | extension | | extension |
| | | | | |
+-----+-----+ +------+-----+ +------+-----+
| | |
| | |
+-------+-------------------+------------------+---------+
| |
| SLAPP (technology-independent framework) |
| |
+--------------------------------------------------------+
Figure 1
Recently, there was a significant amount of interest in a similar
problem in the RFID space that has led to the definition of a simple
lightweight RFID reader protocol (SLRRP) [7]. It is quite possible
that SLRRP could be a technology-specific (RFID, in this case)
extension over a common technology-independent framework.
All of the text in the draft would seem to be written with a WLAN
problem in mind. Please note that while the letter of the draft does
position the solution to solve a CAPWAP-specific problem, the spirit
of the draft is to address the more general problem.
Narasimhan & Harkins Expires October 2, 2005 [Page 6]
Internet-Draft SLAPP March 2005
3. Topology
The SLAPP protocol supports multiple topologies for interconnecting
WTPs and ACs as indicated in Figure 2.
In Figure 2, we have captured four different interconnection
topologies.
1. The WTP is directly connected to the AC without any intermediate
nodes. Many WTPs are deployed in the plenum of buildings and are
required to be powered over the Ethernet cable that is connecting
it to the network. Many ACs in the marketplace can supply power
over etherent and in the case where the AC is the one powering
the WTP, the WTP is directly connected to the AC.
2. The WTP is not directly connected to the AC, but both the AC and
the WTP are in the same L2 (broadcast) domain.
3. The WTP is not directly connected to the AC, and they are not
present in the same L2 (broadcast) domain. They are on two
different broadcast domains and have a node on the path that
routes between two or more subnets.
4. The fourth case is a subset of the third one with the exception
that the intermediate nodes on the path from the WTP to the AC
may not necessarily be in the same administrative domain. The
intermediate network may also span one or more WAN links that may
have lower capacity than if both the AC and the WTP are within
the same building or campus.
Narasimhan & Harkins Expires October 2, 2005 [Page 7]
Internet-Draft SLAPP March 2005
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
Figure 2
Narasimhan & Harkins Expires October 2, 2005 [Page 8]
Internet-Draft SLAPP March 2005
4. Protocol
4.1 Protocol Description
The SLAPP state machine for both the WTP and AC is shown in Figure 3.
Both the WTP and the AC discover each other, negotiate a control
protocol, perform a secure handshake to establish a secure channel
between them, and then use that secure channel to protect a
negotiated control protocol.
The WTP maintains the following variable for its state machine:
abandon: a timer which sets the maximum amount of time the WTP will
wait for an acquired AC to begin the DTLS handshake.
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
Figure 3
4.1.1 State Machine Explanation
Note: the symbol "C" indicates an event which results in the state
remaining the same.
Narasimhan & Harkins Expires October 2, 2005 [Page 9]
Internet-Draft SLAPP March 2005
Discovering
AC: this is a quiescent state for the AC in which it waits for
WTPs to request its acquisition. When a request is received
the AC transitions to Acquiring.
WTP: the WTP is actively discovering an AC. When the WTP receives
a response to its discovery request it transitions to
Acquiring.
Acquiring
AC: a discover request from a WTP has been received. If the
request is invalid or the AC wishes to not acquire the WTP it
drops the packet and transitions back to Discovering.
Otherwise a discovery response is sent and the AC transitions
to Securing.
WTP: a discover response from an AC has been received. If the
response is not valid the WTP transitions to Discovering,
otherwise it sets the abandon timer to a suitable value to
await a DTLS exchange. If the timer fires in Acquiring the WTP
transitions back to Discovering. If a DTLS "client hello" is
received the WTP transitions to Securing and cancels the
abandon timer.
Securing
AC: The AC performs the "client end" of the DTLS exchange. Any
error in the DTLS exchange results in the AC transitioning to
Discovering. When the DTLS exchange finishes the AC
transitions to Negotiated Control Protocol.
WTP: The WTP performs the "server end" of the DTLS exchange. Any
error in the DTLS exchange results in the WTP transitioning to
Discovering. When the DTLS exchange finishes the WTP
transitions to the Negotiated Control Protocol.
Negotiated Control Protocol
AC: the AC performs its side of the protocol agreed to during the
discovery process. (For the Image Download Protocol example
see section Section 6).
WTP: the WTP performs its side of the protocol agreed to during
the discovery process. (For the Image Download Protocol
example see section Section 6).
4.2 Format of a SLAPP Header
All SLAPP packets begin with the same header as shown in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Narasimhan & Harkins Expires October 2, 2005 [Page 10]
Internet-Draft SLAPP March 2005
Where:
Maj (4 bits): the major number of the SLAPP version
Min (4 bits): the minor number of the SLAPP version
Type (1 octet): the type of SLAPP message
Length (two octets): the length of the SLAPP message, including
the entire SLAPP header
The following types of SLAPP messages have been defined:
name type
------ ------
discovery request 1
discovery response 2
image download control 3
reserved 4-255
4.3 Version
SLAPP messages include a version in the form of major.minor. This
document describes the 1.0 version of SLAPP, that is the major
version is one (1) and the minor version is zero (0).
Major versions are incremented when the format of a SLAPP message
changes or the meaning of a SLAPP message changes such that it would
not be properly parsed by an older, existing version of SLAPP. Minor
versions are incremented when some incremental additions have been
made to SLAPP that enhance its capabilities or convey additional
information in a way that does not change the format or meaning of
the SLAPP message.
Future versions of SLAPP MAY NOT mandate support for earlier major
versions of SLAPP so an implementation MUST NOT assume that a peer
that supports version "n" will therefore support version "n - i"
(where both "n" and "i" are non-zero integers and "n" is greater than
"i").
A SLAPP implementation that receives a SLAPP message with a higher
major version number MUST drop that message. A SLAPP implementation
that receives a SLAPP message with a lower major version SHOULD drop
down to the version of SLAPP the peer supports. If that version of
SLAPP is not supported the message MUST be dropped. There may be
valid reasons for which a peer wishes to drop a SLAPP message with a
supported major version though.
A SLAPP implementation that receives a SLAPP message with a higher
minor version number MUST NOT drop that message. It MUST respond
with the minor version number that it supports and will necessarily
Narasimhan & Harkins Expires October 2, 2005 [Page 11]
Internet-Draft SLAPP March 2005
not support whatever incremental capabilities were added that
justified the bump in the minor version. A SLAPP implementation that
receives a SLAPP message with a lower minor version MUST NOT drop
that message. It SHOULD revert back to the minor version which the
peer supports and not include any incremental capabilities that were
added which justified the bump in the minor version.
4.4 Retransmission
SLAPP is a request response protocol. Discovery and security
handshake requests are made by the WTP and responses to them are made
by the AC. Image download packets are initiated by the AC and
acknowledged by the WTP (in a negative fashion, see Section 6).
Retransmissions are handled solely by the initiator of the packet.
After each packet for which a response is required is transmitted,
the sender MUST set a retransmission timer and resend the packet upon
its expiry. The receiver MUST be capable of either regenerating a
previous response upon receipt of a retransmitted packet or caching a
previous response and resending upon receipt of a retransmitted
packet.
The retransmission timer MUST be configurable and default to one (1)
second. No maximum or minimum for the timer is specified by this
version of SLAPP.
Each time a retransmission is made a counter SHOULD be incremented
and the number of retransmissions attempted by a sender before giving
up and declaring a SLAPP failure SHOULD be four (4)-- that is, the
number of attempts made for each packet before declaring failure is
five (5).
The exception to this rule is Image Download packets which are not
individually acknowledged by the WTP (see Section 6). The final
packet is acknowledged and lost packets are indicated through Image
Download Requests.
4.5 Discovery
When a WTP boots up and wants to interoperate with an Access
Controller so that it can be configured by the AC, one of the first
things it needs to do is to discover one or more ACs in its network
neighborhood. This section contains the details of this discovery
mechanism.
As described in Section 3, an AC and a WTP could reside in the same
layer 2 domain, or be separated by a layer 3 cloud including
intermediate clouds that are not under the same administrative domain
Narasimhan & Harkins Expires October 2, 2005 [Page 12]
Internet-Draft SLAPP March 2005
(for example, an AC and a WTP separated by a wide-area public
network). So any proposed discovery mechanism should have provisions
to enable a WTP to discover an AC across all these topologies.
We assume that a WTP prior to starting the discovery process has
already obtained an IP address on its wired segment.
4.5.1 SLAPP Discover Request
The SLAPP discovery process is initiated by sending a SLAPP discover
request packet. The packet can be addressed to the broadcast IP
address, a well known multicast address, or (if the IP address of an
AC is either configured prior to the WTP booting up or is learned
during the boot-up sequence) addressed to a unicast IP address. Lack
of a response to one method of discovery SHOULD result in the WTP
trying another method of discovery. The SLAPP discover request
packet is a UDP packet addressed to port [TBD] designated as the
SLAPP discovery port. The source port can be any random port. The
payload of the SLAPP discover request packet is shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n controltypes| control type | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
4.5.1.1 Transaction ID
The transaction ID is a randomly generated 32-bit number that is
maintained during one phase of the SLAPP discovery process. It is
Narasimhan & Harkins Expires October 2, 2005 [Page 13]
Internet-Draft SLAPP March 2005
generated by a WTP starting a discovery process. When one discovery
method fails to find an AC and the WTP attempts another discovery
method it MUST NOT reuse the Transaction ID. All ACs that intend to
respond to a SLAPP discover request must use the same value for this
field as in the request frame.
4.5.1.2 WTP Identifier
This field allows the WTP to specify a unique identifier for itself.
This MAY be, for instance, its 48-bit MAC address or it could be any
other string such as a serial number.
4.5.1.3 Flags
The flags field is used to indicate certain things about the discover
request. For example, bit 0 in the flags field indicates whether the
discover request packet is being sent to the AC, if unicast, based on
a configuration at the WTP or based on some other means of discovery.
This bit should always be set to the discover mode if the SLAPP
discover request packet is being sent to either a broadcast or
multicast address. Here are the valid values for various bits in the
Flags field.
Bit 0:
0 - Configuration mode
1 - Discover mode
Bits 1-15:
Must always be set to 0 by the transmitter
Must be ignored by the receiver
4.5.1.4 WTP Vendor ID
This 32-bit field is the WTP vendor's SMI enterprise code in network
octet order (these enterprise codes can be obtained from, and
registered with, IANA).
4.5.1.5 WTP HW Version
This 32-bit field indicates the version of hardware present in the
WTP. This is a number that is totally left to the WTP vendor to
choose.
4.5.1.6 WTP SW Version
This 32-bit field indicates the version of software present in the
WTP. This is a number that is totally left to the WTP vendor to
Narasimhan & Harkins Expires October 2, 2005 [Page 14]
Internet-Draft SLAPP March 2005
choose.
4.5.1.7 number of control types
This 8-bit field indicates the number of 8-bit control protocol
indicators that follow it and therefore implicitly indicates the
number of different control protocols the the WTP is capable of
supporting. This number MUST be at least one (1).
4.5.1.8 control types
This 8-bit field indicates the type of control protocol the WTP
supports and is willing to use when communicating with an AC. There
MAY be multiple "control type" indicators in a single SLAPP Discover
Request.
Valid control types
-------------------
0 - RESERVED (MUST not be used)
1 - Image Download Control Protocol
2-255 - RESERVED (to IANA)
4.5.2 SLAPP Discover Response
An AC that receives a SLAPP discover request packet from a WTP can
choose to respond with a SLAPP discover response packet. The format
of the SLAPP discover response packet is shown in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| control type |
+-+-+-+-+-+-+-+-+
Narasimhan & Harkins Expires October 2, 2005 [Page 15]
Internet-Draft SLAPP March 2005
Figure 6
The SLAPP discover response packet is a UDP packet. It is always
unicast to the WTP's IP address. The source IP address is that of
the AC sending the response. The source port is the SLAPP discover
port [TBD] and the destination port is the same as the source port
used in the SLAPP discover request. The WTP's MAC address and the
transaction ID must be identical to the values contained in the SLAPP
discover request. The Status field indicates to the WTP whether the
AC is either accepting the discover request and is willing to allow
the WTP to proceed to the next stage (ACK) or whether it is denying
the WTP's earlier request (NACK). The AC includes its own vendor ID,
hardware and software versions in the response.
4.5.2.1 Transaction ID
The value of the Transaction ID field should be identical to its
value in the SLAPP discover request packet sent by the WTP.
4.5.2.2 WTP Identifier
The WTP Identifier that was sent in the corresponding SLAPP discover
request frame.
4.5.2.3 Flags
This field is unused by this version of SLAPP. It MUST be set to
zero (0) on transmission and ignored upon receipt.
4.5.2.4 AC Vendor ID
If the value of the status field is a 1, indicating that the AC is
sending a successful response, then the values in this field and the
following two are valid. The 32-bit AC Vendor ID points to the
vendor ID of the AC. If the value of the status field is not 1, then
this field should be set to 0 by the AC and ignored by the WTP.
4.5.2.5 AC HW Version
If the value of the status field is 1, then this 32-bit field
contains the value of the AC's hardware version. This value is
chosen by the AC vendor. If the value of the status field is not a
1, then this field should be set to 0 by the AC and ignored by the
WTP.
4.5.2.6 AC SW Version
If the value of the status field is 1, then this 32-bit field
Narasimhan & Harkins Expires October 2, 2005 [Page 16]
Internet-Draft SLAPP March 2005
contains the value of the AC's software version. This value is
chosen by the AC vendor. If the value of the status field is not a
1, then this field should be set to 0 by the AC and ignored by the
WTP.
4.5.2.7 Control Type
The control type the AC will use to communicate with the WTP. This
value MUST match one of the control types passed in the corresponding
SLAPP Discover Request.
4.6 SLAPP Discovery Process
4.6.1 WTP
There are multiple ways in which a WTP can discover an AC.
1. Static configuration: An administrator, prior to deploying a WTP,
can configure an IP address of an AC on the WTP's non-volatile
memory. If this is the case, then the SLAPP discover request
packet is addressed to the configured IP address.
2. DHCP options: As part of the DHCP response, the DHCP server could
be configured to use option 43 to deliver the IP address of an AC
to which the WTP should address the SLAPP discover request
packet. If the IP address of an AC is handed to the WTP as part
of the DHCP response, then the WTP should address the SLAPP
discover request packet to this IP address.
3. DNS configuration: Instead of configuring a static IP address on
the WTP's non-volatile memory, an administrator can configure a
FQDN of an AC. If the FQDN of an AC is configured, then the WTP
queries its configured DNS server for the IP address associated
with the configured FQDN of the AC. If the DNS query is
successful and the WTP acquires the IP address of an AC from the
DNS server, then the above discover request packet is addressed
to the unicast address of the AC.
4. Broadcast: The WTP sends a discover request packet addressed to
the broadcast IP address with the WTP's IP address as the source.
A network administrator, if necessary, could configure the
default router for the subnet that the WTP is on with a helper
address and unicast it to any address on a different subnet.
5. IP Multicast: A WTP can send the above payload to a SLAPP IP
multicast address [TBD].
6. DNS: If there is no DNS FQDN configured on the WTP, and the WTP
is unable to discover an AC by any of the above methods, then it
should attempt to query the DNS server for a well known FQDN of
an AC [TBD]. If this DNS query succeeds, then the WTP should
address the SLAPP discover request packet to the unicast address
of the AC.
Narasimhan & Harkins Expires October 2, 2005 [Page 17]
Internet-Draft SLAPP March 2005
The above process is summarized in the sequence shown in Figure 7.
SLAPP discovery start:
Static IP address config option:
Is a static IP address for an AC configured?
If yes, send SLAPP discover request to that unicast IP address
SLAPP discover response within discovery_timer?
If yes, go to "done"
If not, go to "Static FQDN config option"
If not, go to "Static FQDN config option"
Static FQDN config option:
Is a static FQDN configured?
If yes, send a DNS query for the IP address for the FQDN.
Is DNS query successful?
If yes, send SLAPP discover request to that IP address
SLAPP discover response within discovery timer?
If yes, go to "done"
If not, go to "DHCP options option"
If not, go to "DHCP options option"
DHCP options option:
Is the IP address of an AC present in the DHCP response?
If yes, send SLAPP discover request to the AC's IP addr
SLAPP discover response within discovery timer?
If yes, go to "done"
If not, go to "Broadcast option"
If not, go to "Broadcast option"
Broadcast option:
Send SLAPP discover packet to the broadcast address
SLAPP discover response within discovery timer?
If yes, go to "done"
If not, go to "Multicast option"
Multicast option:
Send SLAPP discover packet to the SLAPP multicast address
SLAPP discover response within discovery timer?
If yes, go to "done"
If not, go to "DNS discovery option"
DNS discovery option:
Query the DNS server for a well known DNS name
Is the DNS discovery successful?
If yes, send SLAPP discover request to that IP addr
SLAPP discover response within discovery timer?
If yes, go to "done"
If not, go to "SLAPP discovery restart"
If not, go to "SLAPP discovery restart"
SLAPP discovery restart:
Set timer for SLAPP discovery idle timer
When timer expires, go to "SLAPP discovery start"
Narasimhan & Harkins Expires October 2, 2005 [Page 18]
Internet-Draft SLAPP March 2005
done:
go to the next step
Figure 7
4.6.2 AC
When an AC receives a SLAPP discover request it must determine
whether it wishes to acquire the WTP or not. An AC MAY only agree to
acquire those WTPs whose WTP Identifiers are statically configured in
its configuration. Or an AC that is willing to gratuitously acquire
WTPs MAY accept any request pending authentication. An AC MUST only
choose to acquire WTPs that speak a common Negotiated Control
protocol but other factors may influence its decision. For instance,
if the Negotiated Control Protocol is the Image Download protocol
defined in this memo the AC MUST NOT acquire a WTP for which it does
not have a compatible image to download as determined by the WTP's HW
Vendor ID, HW Version and Software Version. Whatever its decision,
the AC MUST respond one of two ways.
1. The AC sends a SLAPP discover response indicating its agreement
to acquire the WTP.
2. The AC silently drops the SLAPP discover request and does not
respond at all.
Narasimhan & Harkins Expires October 2, 2005 [Page 19]
Internet-Draft SLAPP March 2005
5. Security Association
Once an AC has been discovered by a WTP and agreed to acquire it (by
sending a Discovery Response) it will initiate a DTLS [5] exchange
with the WTP by assuming the role of the "client". The WTP assumes
the role of the "server". The port used by both the WTP and AC for
this exchange will be [TBD].
An obvious question is "why is the AC acting as a client?" The reason
is to allow for non-mutual authentication in which the WTP is
authenticated by the AC (see Section 5.1.2).
Informational note: DTLS is used because it provides a secure and
connectionless channel using a widely accepted and analyzed protocol.
In addition, the myriad of authentication options in DTLS allows for
a wide array of options with which to secure the channel between the
WTP and the AC-- mutual and certificate based; asymmetric or
non-mutual authentication; anonymous authentication; etc.
Furthermore, DTLS defines its own fragmentation and reassembly
techniques as well as ways in which peers agree on an effective MTU.
Using DTLS obviates the need to redefine these aspects of a protocol
and therefore lessens code bloat as the same problem doesn't need to
be solved yet again in another place.
Failure of the DTLS handshake protocol will cause both parties to
abandon the exchange. The AC SHOULD blacklist this WTP for a period
of time to prevent a misconfigured WTP from repeatedly discovering
and failing authentication. The WTP MUST return to the discovery
state of SLAPP to locate another suitable AC with which it will
initiate a DTLS exchange.
Once the DTLS handshake has succeeded the WTP and AP transition into
"image download state" and protect all further SLAPP messages with
the DTLS-negotiated cipher suite.
5.1 Example Authentication Models (Informative)
Any valid cipher suite in [6] can be used to authenticate the WTP
and/or the AC. Different scenarios require different authentication
models. The following examples are illustrative only and not meant
to be exhaustive.
Since neither side typically involves a human being a
username/password based authentication is not possible.
Zero-config requirements on certain WTP deployments can predicate
certain authentication options and eliminate others.
Narasimhan & Harkins Expires October 2, 2005 [Page 20]
Internet-Draft SLAPP March 2005
5.1.1 Mutual Authentication
When mutually authenticating, the WTP authenticates the AC, thereby
ensuring that the AC to which it is connecting is a trusted AC, and
the AC authenticates the WTP, thereby ensuring that the WTP that is
connecting is a trusted WTP.
Mutual authentication is typically achieved by using certificates on
the WTP and AC which ensure public keys each party owns. These
certificates are digitally signed by a Certification Authority, a
trusted third party.
Enrolling each WTP in a Certification Authority is outside the scope
of this document but it should be noted that a manufacturing
Certification Authority does not necessarily provide the level of
assurance necessary as it will only guarantee that a WTP or AC was
manufactured by a particular company and cannot distinguish between a
trusted WTP and a WTP which is not trusted but was purchased from the
same manufacturer as the AC.
5.1.2 WTP-only Authentication
Some deployments may only require the WTP to authenticate to the AC
and not the other way around.
In this case the WTP has a keypair which can uniquely identify it
(for example, using a certificate) and that keypair is used in a
"server-side authentication" [6] exchange.
This authentication model does not authenticate the AC and a rogue AC
could assert control of a valid WTP. It should be noted, though,
that this will only allow the WTP to provide service for networks
made available by the rogue AC. No unauthorized network access is
possible.
5.1.3 Anonymous Authentication
In some deployments it MAY just be necessary to foil the casual
snooping of packets. In this case an unauthenticated, but encrypted,
connection can suffice. Typically a Diffie-Hellman exchange is
performed between the AC and WTP and the resulting unauthenticated
key is used to encrypt traffic between the AC and WTP.
Narasimhan & Harkins Expires October 2, 2005 [Page 21]
Internet-Draft SLAPP March 2005
6. Image Download Protocol
The Image Download protocol is an extension to SLAPP that is generic
enough that it is agnostic to the underlying technology.
In the image download protocol, the WTP obtains a bootable image from
the AC by receiving a series of image transfer packets. Missed image
data packets are re-requested by the WTP by sending image data
request packets indicating the missing packets.
The image to download is divided into slices of equal size (except
for the last slice which can be less than the slice size provided it
is also greater than zero). The size of each slice depends on the
MTU determined by the DTLS exchange and SHOULD be the realized MTU
minus the size of an Image Download Request (Figure 9).
Note that the image download packet and download image request is
encapsulated in a DTLS header which secures the image download.
6.1 Image Download Packet
The format of an image download packet is shown in Figure 8.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ image data slice ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
where:
length: variable
RESERVED: unused in this version of SLAPP, MUST be zero (0) on
transmission and ignored upon receipt
M: the "More" bit indicating that the current packet is not the final
one
R: the "Request" bit. This bit MUST be set to one (1) when the
packet is the response to a request and zero (0) otherwise.
packet sequence number: a monotonically increasing counter which
assigns a unique number to each slice of the image
Narasimhan & Harkins Expires October 2, 2005 [Page 22]
Internet-Draft SLAPP March 2005
image data slice: a portion of the bootable image.
6.2 Image Download Request
The format of an image download request is show in Figure 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 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
where:
length: eight (8) octets
RESERVED: unused in this version of SLAPP, MUST be zero on
transmission and ignored upon receipt
M: the "More" bit. This MUST be equal to the one (1) when negatively
acknowledging a missed packet and set to zero (0) when indicating
the end of the Image Download protocol.
R: the "Request" bit. This MUST be one in an Image Download Request.
packet sequence number: the packet sequence number of the missing
image data slice.
6.3 Image Download Process
The AC will divides the bootable image into a series of slices and
sends each slice as an Image Download packet. The size of each image
data slice (and therefore the size of each image download packet)
depends on the MTU of the connection determined during the DTLS
handshake. With the transmission of each slice the AC MUST increment
the packet sequence number.
Image Download packets are negatively ack'd. An AC MUST NOT assume
anything about the reception of packets it sends based upon negative
acks. One could naively assume that since the packets are sent
sequentially that all packets with a sequence number of "n - 1" are
implicitly ack'd by the receipt of a request for the packet with
sequence number "n" to be retransmitted. Such an assumption would be
incorrect since previous requests could, themselves, have been
dropped.
The image download process is initiated by the WTP requesting a
packet with the packet sequence number of zero (0). The AC sets the
packet sequence counter for this WTP to one (1) and sends the first
Narasimhan & Harkins Expires October 2, 2005 [Page 23]
Internet-Draft SLAPP March 2005
slice. The "Request" bit for the first slice sent by the AC MUST be
set to zero (0) since the first slice was technically not requested.
The WTP sets a periodic timer that, when it fires, causes the WTP to
sends Image Download requests for slices that have been missed since
the last periodic timer had fired. Since individual Image Download
packets are not ack'd the AC MUST NOT set a timer when each one is
sent.
If a WTP notices missed image transfer packets-- when the difference
between the packet sequence number of a received image transfer
packet and the packet sequence number of the last image transfer
packet previously received is greater than one-- it will note that
fact in a bitmask. When the periodic timer fires the WTP will
request the slices that are absent from that bitmask. Each slice
will be requested by sending a Download Request with a length of
eight (8) and indicating the sequence number of the packet requested.
The AC MUST interleave these retransmissions with packets in the
sequence.
Since both sides implicitly agree upon the MTU of the link the WTP
will know the slice size that the AC will use during the Image
Download process. A dropped packet will therefore result in an
internal buffer pointer on the WTP being incremented by the slice
size and the lost packet requested. When the lost packet is received
it can be inserted into the buffer in the space provided by the
pointer increment when its loss was first detected. That is, loss of
packet <n> will result in packet <n> being re-requested and when
received inserted into the buffer at an offset of <n-1> * <slicesize>
from the start of the buffer.
The final packet sent by the AC will not have the "more" bit set and
this indicates to the WTP that the end of the image has been
received. This final packet is acknowledged by the WTP indicating
the end of the Image Download process.
A lost final packet will result in the AC resending the final packet
again (see Section 4.4).
6.4 Image Download State Machine
The Image Download protocol is a negotiated control protocol defined
for SLAPP. Transitions to it come from the "secure" state and
transitions out of it go to "acquire". See Figure 3.
6.4.1 AC
The AC's state machine for the Image Download protocol is shown in
Narasimhan & Harkins Expires October 2, 2005 [Page 24]
Internet-Draft SLAPP March 2005
Figure 10. The AC maintains the following variables for its state
machine:
seq_num: the current slice that is being sent
nslices: the total number of slices in the image
req_num: the number of the slice that was requested
more: whether the "More bit" in the packet should be set
starved: a timer which sets the maximum amount of time in which an AC
will attempt to download an image.
Note: the symbol "C" indicates an event in a state which results in
the state remaining the same.
|
v
+----------+
| waiting |
+----------+
|
| seq_num = 1, more = 1,
| nslices = x, starved = t
M bit v
+----------+ is 0 +-------------+
| finished |<-------| received |<------\
+----------+ | |<----\ |
+-------------+ | |
req_num = requested | | |
packet | M bit is 1 | |
V | |
+----------+ | |
seq_num++, C| sending |------/ |
req_num=0 +----------+ |
| |
| | |
+-------------+ | | |
| discovering |<----/ | |
| |<----\ | |
+-------------+ | | |
| v v
+--------+ |
| idle |---------/
+--------+
Figure 10
The following states are defined:
Narasimhan & Harkins Expires October 2, 2005 [Page 25]
Internet-Draft SLAPP March 2005
Waiting: When the AC leaves the SLAPP state of "Secure" it enters the
"Waiting" state of the Image Download protocol. seq_num is set to
one (1), more is set to one (1), and nslices is set to the number
of slices in the particular image to download, and starved is set
to the maximum amount of time the AC will devote to downloading a
particular image.
Received: The AC enters this state when it has received an Image
Download request. If the sequence number of the packet is zero
(0) it sets seq_num to one (1) and transitions to Sending, else if
the M bit is set it sets req_num to the sequence number of the
request and transitions to Sending else (if the M bit is clear) it
transitions to Finished.
Sending: The AC is sending a slice to the WTP. If req_num is equal
to zero (0) it sends the slice indicated by seq_num and increments
seq_num. If req_num is greater than zero (0) it sends the slice
indicated by req_num and sets req_num to zero (0). The "More" bit
in either case is set depending on the value of more. As long as
no request packets are received Sending transitions to Sending.
When seq_num equals nslices "More" is set to zero (0) and the
state transitions to Idle. If the starved timer expires the AC
transitions to the SLAPP state of Discovering.
Idle: The AC has sent all the slices in the image and is just waiting
for requests. If the starved timer expires the AC transitions to
the SLAPP state of Discovering.
Finished: The Image Download protocol has terminated. The starved
timer is canceled.
6.4.2 WTP
The WTP's state machine for the Image Download protocol is shown in
Figure 11. The WTP maintains the following variables for its state
machine:
recv_num: the sequence number of the last received slice
req: a bitmask whose length equals the number of slices in the image
retry: a timer
giveup: a timer
final: the sequence number of the last slice
Note: the symbol "C" indicates an event in a state which results in
the state remaining the same.
Narasimhan & Harkins Expires October 2, 2005 [Page 26]
Internet-Draft SLAPP March 2005
|
v
+----------+
| init | recv_num = 0,
+----------+ final = 0, req = 0,
| giveup = t
v
+----------+ +-----------+
| finished |<------- | sending |<-------\
+----------+ +-----------+ |
| | retry fires
v |
+--------------+ |
bit in req = C| receiving |------/
seq_num in packet +--------------+
is set |
| giveup fires
v
+-------------+
| discovering |
+-------------+
Figure 11
The following states are defined:
Init:
When the WTP leaves the SLAPP state of "Secure" it enters the
"Init" state of the Image Download Protocol. recv_num, final, and
the req bitmask are set to zero (0), and the giveup timer is set
to a suitably large number. The WTP transitions directly to
Sending.
Sending:
If recv_num is zero (0) the WTP sends a request for a packet with
sequence number of zero (0) and the "More" bit set to one (1).
Otherwise for every unset bit in req between one (1) and recv_num
a request packet is sent with the sequence number corresponding to
the unset bit in req and the "More" bit set to more.
If there are no unset bits in req and final is non-zero a request
packet is sent for the sequence number represented by final with
the "More" bit cleared, giveup is cleared and the state machine
transitions to Finished. Otherwise retry is set to a suitable
value and the WTP transitions to Receiving.
Receiving:
In this state the WTP receives Image Download packets. The bit in
req corresponding to the sequence number in the received packet
is set indicating this packet has been received. If the sequence
number of the received packet has already been received the packet
is silently dropped, otherwise the data in the packet is stored as
Narasimhan & Harkins Expires October 2, 2005 [Page 27]
Internet-Draft SLAPP March 2005
the indicated slice in a file which represents the downloaded
image. If the received packet has the "More" bit cleared final is
set to the sequence number in that packet. When the retry timer
fires the WTP transitions to Sending. If the giveup timer fires
the WTP transitions to the SLAPP state of Discovering.
Finished:
The image download protocol has finished.
Narasimhan & Harkins Expires October 2, 2005 [Page 28]
Internet-Draft SLAPP March 2005
7. Security Considerations
This document describes a protocol, SLAPP, which uses a different
protocol, DTLS, to provide for authentication, key exchange, and bulk
data encryption of a negotiated control protocol. It's security
considerations are therefore those of DTLS.
The AC creates state upon receipt of an acceptable Discovery Request.
AC implementations of SLAPP SHOULD therefore take measures to protect
themselves from denial of service attacks which attempt to exhaust
resources on target machines. These measures could take the form of
randomly dropping connections when the number of open connections
reaches a certain threshold.
The WTP exposes information about itself during the discovery phase.
Some of this information could not be gleaned by other means.
Narasimhan & Harkins Expires October 2, 2005 [Page 29]
Internet-Draft SLAPP March 2005
8. Extensibility to other technologies
The SLAPP protocol can be considered to be a technology-independent
protocol that can be extended with technology-specific components to
solve an interoperability problem where a central controller from one
vendor is expected to control and manage network elements from a
different vendor.
While the description of the SLAPP protocol in this draft assumes
that it is meant to solve the multi-vendor interoperability problem
as defined in the CAPWAP problem statement [3], splitting the
solution to two components where technology-dependent extensions are
combined with a technology-independent framework enables the use of
SLAPP as the common framework for multiple underlying technologies
that are vastly different from one another.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[2] "Architecture Taxonomy for Control and Provisioning of Wireless
Access Points(CAPWAP)", August 2004,
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-capwap-arch-06.txt
>.
[3] "Configuration and Provisioning for Wireless Access Points
(CAPWAP) Problem Statement", February 2005,
<http://www.ietf.org/rfc/rfc3990.txt>.
[4] Govindan, S., "Objectives for Control and Provisioning of
Wireless Access Points (CAPWAP)", November 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-capwap-objective
s-00.txt>.
[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", February 2004,
<http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt>
.
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999,
<ftp://ftp.isi.edu/in-notes/rfc2246.txt>.
[7] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader
Protocol", March 2005,
<http://www.ietf.org/internet-drafts/draft-krishna-slrrp-01.txt>
.
Narasimhan & Harkins Expires October 2, 2005 [Page 30]
Internet-Draft SLAPP March 2005
Authors' Addresses
Partha Narasimhan
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 408-480-4716
Email: partha@arubanetworks.com
Dan Harkins
Trapeze Networks
5753 W. Las Positas Blvd
Pleasanton, CA 94588
Phone: +1-925-474-2212
Email: dharkins@trpz.com
Narasimhan & Harkins Expires October 2, 2005 [Page 31]
Internet-Draft SLAPP March 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narasimhan & Harkins Expires October 2, 2005 [Page 32]