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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 30 Nov 2006 06:41:36 -0800

ok - I will make the necessary change and incorporate your text once you
send it to me.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 4:23 AM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use 
> of Session ID
> 
> 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
> 
> Pat Calhoun (pacalhou) wrote:
> > 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