Subject: [Capwap] comments to draft-ietf-capwap-protocol-specification-03

From: Jakob Schlyter <[email-masked]>
Date: Thu, 9 Nov 2006 08:25:58 -0800

hi,

I believe this was just discussion in the WG meeting and since I'm  
not a active participant of the CAPWAP mailinglist, I just want to  
note that DTLS does contains a session identifier (ref: TLS, RFC 4346  
section 7).

also, regarding the port allocation I wanted to ask if the WG has  
considered the use of DNS SRV RR for looking up the ports used? e.g.

	_capwap-ctrl._dtls.ac.example.com.	IN SRV ...
	_capwap-tun._dtls.ac.example.com.	IN SRV ...
vs
	_capwap-ctrl._udp.ac.example.com.	IN SRV ...
	_capwap-tun._udp.ac.example.com.	IN SRV ...

see draft-lear-iana-no-more-well-known-ports-02.txt for more text  
about this.

finally, I'd like to state that putting the whole CAPWAP inside DTLS  
would ease implementation in cases when the DTLS stack directly plugs  
in top of the the UDP stack, since once DTLS is stripped off the  
packet we have a clean CAPWAP packet left. this would also help  
vendors putting DTLS accelleration outside of the actual AC software  
(which is done today with TLS/SSL accelerators for high bandwith  
applications).

regards,

	jakob

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

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

---

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

Hi Jakob,

Comments inline below...

-----Original Message-----
>From: Jakob Schlyter <[email-masked]>
>Sent: Nov 9, 2006 8:25 AM
>To: [email-masked]
>Subject: [Capwap] comments to draft-ietf-capwap-protocol-specification-03
>
>hi,
>

I think the confusion here is the result of my unfortunate choice of terms, and perhaps also from some missing context. You are correct: there is a session identifier defined in the TLS spec. This identifier is passed in the handshake, and can be used for session resumption. However, the record layer is unaware of this value, meaning it is not passed in data packets. Also, in the current openssl api, the application remains blissfully unaware of this value.

What I was trying to say is that for datagram sockets, the application is reponsible for finding the openssl session associated with the packet prior to giving the packet to openssl. For TCP server sockets this is not a problem, as you listen() on the server socket/port, and then when you accept() an inbound connection, a new socket which is explicitly bound to the socket (and by extension, the 5-tuple associated with that packet). This provides an implicit binding between the ssl 'session', the given socket, and the application-level 'session'

It is entirely possible that a way exists and I simply have yet to find it, but I have not yet figured out how to implement similar functionality for datagram sockets using the BSD sockets abstraction. I realized once I started typing this response that this does not mean there is no way to do this - only that I haven't figured it out yet if there is. But the bottom line problem is that we need a binding between the 5-tuple, the DTLS 'session', and the CAPWAP 'session'.  If anyone here knows of a reliable way to do this with datagram sockets. please speak up. 

Regardless, we need to document (from a security requirements perspective) the criticality of this binding requirement, and we need to make clear that when CAPWAP receives a protected PDU (that has been 'unwrapped'), it MUST be able to verify that the PDU's cryptographic context was the 'right' one.

Scott