Subject: [Capwap] Proposed Resolution for Issue 127: Use of Session ID

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 09:43:01 -0800

All,

Following the proposal made at the IETF meeting in San Diego, please
find below the proposed text for the handling of this issue:

4.2.  CAPWAP Header

[...]

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|     Flags     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Fragment ID          |     Frag Offset         |Rsvd |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Session ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Session ID:  The 32-bit field contains a pseudo-random session
      identifier thatis used to help match control frames with data
      frames.  The use of the Session ID field is further described in
      Section 6.1.
[...]

5.1.  Discovery Request Message
[...]
   The Discovery Request message may be sent as a unicast, broadcast or
   multicast message.  The Session ID field in the CAPWAP Header MUST be
   set to zero as it is unused in all Discovery messages.

[...]
5.2.  Discovery Response Message
[...]

   The Discovery Response message is sent by an AC after receiving a
   Discovery Request message from a WTP.  As with the Discovery Request,
   the Session ID field in the CAPWAP header MUST be set to zero.
[...]

6.1.  Join Request
[...]

   The WTP includes a pseudo-random 32 bit Session ID in the CAPWAP
   Header (see Section 4.2).  The Session ID MUST remain the same across
   all future CAPWAP control and data packets sent by both the WTP and
   the AC to identify the specific CAPWAP session.  The WTP and AC MUST
   ensure that all future packets received with the same Session ID have
   the same source IP Address and UDP Port Number.
[...]
11.  NAT Considerations

[...]

   It is, however, possible for two or more WTPs to reside behind the
   same NAT system.  In this instance, the AC would receive multiple
   connection requests from the same IP address, and could end up
   thinking all of the connection requests come from the same WTP.  It
   is important that the AC not disconnect another WTP's session as a
   result of this situation occuring.  Therefore, the AC should consider
   the WTP's identity, which is communicated within the DTLS exchange
   used to secure the CAPWAP control channel.  The CAPWAP header
   includes a Session Identifier field, which is used to match the
   control and data plane.  This allows the AC to match the control and
   data plane flows from multiple WTPs behind the same NAT system
   (therefore all sharing the same IP address).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Charles Clancy <[email-masked]>
Date: Thu, 30 Nov 2006 07:22:44 -0500

I agree with keeping the Session ID.  However, I think its length should 
be increased to at least 64 bits to make it difficult to guess if both 
control and data channels are encrypted.

I think we also need some text in the security considerations section 
about bindings between the DTLS and CAPWAP layers.  Since the DTLS API 
doesn't export a session ID for us to use, implementations will need to 
be sure some unique identifier is available to associate decrypted 
CAPWAP packets with the correct WTP session at the AC.  The session ID 
in the CAPWAP header is not bound to DTLS in any way, so it is by itself 
insufficient.  I wrote some text after the IETF... I'll try and dig it up.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy