Issue172

Title How is the WTP Descriptor's Encryption Capabilities defined?
Priority bug Status resolved
Superseder Nosy List pcalhoun
Assigned To pcalhoun Topics

Created on 2008-07-31.16:58:48 by pcalhoun, last changed 2008-08-20.13:31:59 by pcalhoun.

Messages
msg504 (view) Author: pcalhoun Date: 2008-08-20.13:31:59
Fixed in draft-ietf-capwap-protocol-specification-12.txt
msg494 (view) Author: pcalhoun Date: 2008-08-13.22:18:54
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>
msg454 (view) Author: pcalhoun Date: 2008-07-31.16:58:48
> 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.
History
Date User Action Args
2008-08-20 13:31:59pcalhounsetstatus: chatting -> resolved
messages: + msg504
2008-08-13 22:18:54pcalhounsetstatus: unread -> chatting
messages: + msg494
2008-07-31 16:58:48pcalhouncreate