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

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 30 Nov 2006 10:04:55 -0800 (GMT-08:00)

Hi Jim,

The short answer is that it's required so that you can bind the control and data channel. If the WTP is behind a NAT or load balancer, you can't use the IP address to identify which control channel (or WTP) the data channel is associated with when you see data channel traffic.

Scott

-----Original Message-----
>From: Jim Murphy <[email-masked]>
>Sent: Nov 30, 2006 9:54 AM
>To: "Pat Calhoun (pacalhou)" <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use of Session ID
>
>The text in the current draft does not adequately describe the session 
>ID, nor could I find anything in the recent list archives. Can you 
>provide some explanatory text for this session ID and why it is 
>required? From what I can gather from snippets on the list from Charles, 
>it seems like it should only be required if DTLS is being used for 
>control messages.
>
>Thanks,
>
>Jim
>
>Pat Calhoun (pacalhou) wrote:
>> All,
>> 
>> Here is an update based on feedback I've received:
>> 
>> 1. Changing Session ID field from 32 to 64 bits:
>> 
>> 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                           |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                          Session ID                           |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                 (optional) Radio MAC Address                  |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |            (optional) Wireless Specific Information           |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                        Payload ....                           |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> [...]
>> 
>>    Session ID:  The 64-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.
>> 
>> [...]
>> 6.1.  Join Request
>> [...]
>> 
>>    The WTP includes a pseudo-random 64 bit Session ID in the CAPWAP
>>    Header (see Section 4.2).  
>> 
>> 2. Change ambiguous text
>> 
>> From:
>>    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.
>> 
>> To:
>>    The WTP and AC MUST
>>    ensure that all future control and data packets sent from the
>>    respective IP address and UDP port numbers have the same Session ID.
>> 
>> 
>> Pat Calhoun
>> CTO, Wireless Networking Business Unit
>> Cisco Systems
>> 
>>  
>> 
>>> -----Original Message-----
>>> From: Pat Calhoun (pacalhou) 
>>> Sent: Wednesday, November 22, 2006 9:43 AM
>>> To: [email-masked]
>>> Subject: [Capwap] Proposed Resolution for Issue 127: Use of Session ID
>>>
>>> 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
>>>
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>> 
>> Archives: http://lists.frascone.com/pipermail/capwap
>
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap

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

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 30 Nov 2006 19:04:01 -0800

(a) I am not sure I see the need for a session ID at all. The NAT
gateway should have all the information needed to do this binding even
without the session id.

Unless we can point to a specific case of why this is needed, I would
propose that we delete session id completely.

(b) Also, it seems that we are adding band-aid upon band-aid to a
problem where the real problem is that we decided (at some point in the
distant past before all the issues were known) to use 2 UDP ports. It
would seem that if we got rid of the 2 UDP ports (and moved to a single
udp port with info in the capwap-preamble) we would make the protocol
much simpler and get rid of any binding changes to the NAT gateway
devices. I would strongly urge the WG to look at restricting the capwap
header size and moving to a single UDP port which does away with any NAT
gateway parsing of CAPWAP.

Thanks.

-Puneet

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 10:05 AM
To: Jim Murphy; Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use of Session
ID

Hi Jim,

The short answer is that it's required so that you can bind the control
and data channel. If the WTP is behind a NAT or load balancer, you can't
use the IP address to identify which control channel (or WTP) the data
channel is associated with when you see data channel traffic.

Scott

-----Original Message-----
>Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use of Session

>ID
>required? From what I can gather from snippets on the list from 
>Charles, it seems like it should only be required if DTLS is being used

>for control messages.
|Rsvd |
|
|
|
|
|
>> CTO, Wireless Networking Business Unit Cisco Systems
>> 
>>  
>> 
>>> 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
>>>    The Discovery Request message may be sent as a unicast, broadcast

>>> or
>>>    multicast message.  The Session ID field in the CAPWAP Header 
>>> MUST be
>>>    Discovery Request message from a WTP.  As with the Discovery 
>>> Request,
>>>    Header (see Section 4.2).  The Session ID MUST remain the same 
>>> across
>>>    the AC to identify the specific CAPWAP session.  The WTP and AC 
>>> MUST
>>> have
>>>    result of this situation occuring.  Therefore, the AC should 
>>> consider
>>>    control and data plane.  This allows the AC to match the control 
>>> and
>>> CTO, Wireless Networking Business Unit Cisco Systems

---

From: Scott G Kelly <[email-masked]>
Date: Thu, 30 Nov 2006 20:13:36 -0800

Hi Puneet,

> propose that we delete session id completely.

It is not the NAT gateway (or the load balancer, whichever the case may 
be) that we are concerned with. It is the AC. The AC cannot tell which 
data channel goes with which control channel, and this has important 
operational consequences.

As for the one port vs two port discussion, I agree with you that using 
one port solves this problem and several others, and you may recall that 
I argued this point quite vocally. Nonetheless, that door was slammed 
shut on us long ago, sound reasoning to the contrary notwithstanding.

I doubt you'll get very far arguing about it now. I don't like it, but 
Pat is right: the decision was accepted by you and everyone else here. 
We won't make much progress if we keep dredging these things up again 
and again.

Scott