Capwap Mailing List: Re: Issue 172: How is the WTP Descriptor's EncryptionCapabilities defined?

[Pat Calhoun (pacalhou) (pcalhoun]

All,

In order to make progress on this issue, I will be proposing a change
that breaks backward compatibility. Unfortunately, there is no easy fix,
other than severely limiting protocol extensibility. The fix is to allow
multiple encryption capability fields in the WTP Descriptor, hence
breaking interoperability with -10.

<new text>
4.6.40.  WTP Descriptor

   The WTP Descriptor message element is used by a WTP to communicate
   its current hardware and software (firmware) configuration.  The
   value contains the following fields.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radios  | Radios in use |    Encryption Sub-Element     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Descriptor Sub-Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

   Encryption Sub-Element:   The WTP Descriptor message element MUST
      contain at least one Encryption sub-element.  One sub-element is
      present for each binding supported by the WTP.  The Encryption
      sub-element has the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Resvd|  WBID   |  Encryption Capabilities      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Resvd:  The 3-bit field is reserved for future use.  All
         implementations complying with this protocol MUST set to zero
         any bits that are reserved in the version of the protocol
         supported by that implementation.  Receivers MUST ignore all
         bits not defined for the version of the protocol they support.

      WBID:   A 5 bit field which is the wireless binding identifier.
         The identifier will indicate the type of wireless packet
         associated with the radio.  The WBIDs defined in this
         specification can be found in Section 4.3

      Encryption Capabilities:   This 16-bit field is used by the WTP to
         communicate its capabilities to the AC.  A WTP that does not
         have any encryption capabilities sets this field to zero (0).
         Refer to the specific wireless binding for further
         specification of the Encryption Capabilities field.</new text>

PatC 

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Thursday, July 31, 2008 10:12 AM
To: capwap [at] frascone.com
Cc: Pasi.Eronen [at] nokia.com
Subject: [Capwap] Issue 172: How is the WTP Descriptor's
EncryptionCapabilities defined?

Pasi's comment was:

   > Section 8.1: there probably should be IANA considerations text
about how the 
   > remaining bits are allocated.

The actual issue here is given the number of bits this field has (8),
are we expecting that a given WTP will advertise the encryption
capabilities based on the binding being advertised? This means that
every binding spec would be able to define all 8 bits. Of course, this
would then create a potentially significant problem if a WTP advertises
two separate bindings.

Currently, the new text in the binding specification is:
<new text>
8.1.  WTP Descriptor Message Element, Encryption Capabilities Field:

   This specification defines two new bits for the WTP Descriptor's
   Encryption Capabilities field, as defined in
   [I-D.ietf-capwap-protocol-specification].  Note that only the bits
   defined in this specification are described below.  The format of the
   Encryption Capabilities Field is:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |       |A|T|   |
        +-+-+-+-+-+-+-+-+

   A:   WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].

   T:   WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
      and [WPA], respectively.
</new text>

Again, as currently specified, this means that bits 4 and 5 cannot be
redefined by another binding document. So we have to make a decision of
whether:
1. We allow the bits to be defined entirely by the binding
specification. Prevents a WTP from supporting two different bindings.
2. We allow the bits to be globally allocated. This allows a WTP to
advertise multiple bindings, but it restricts the encryption methods to
8 - for all bindings.
3. Create an interoperability issue by removing the encryption
capabilities field in the base document (or leave the field but mark it
reserved), and require all bindings to define their own encryption
capabilities message element.

Thoughts?

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap