Subject: RE: [Capwap] NAT-T

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 24 Mar 2006 08:22:35 -0800

[...] 

> if ( mux header type is control )
> {
>    if ( dtlsInput(encap'd data) returns error )
>      do error handling
>    else if ( capwapInput(unencap'd data) returns error )
>      do error handling
> }
> else /* it's a data packet */
> {
>    if ( capwapInput(unencap'd data) returns error )
>      do error handling
> }
> 
[...] 
> 
> The only drawback I can see is that you can't use the openssl 
> SSL_read() call directly with the socket (assuming you use 
> sockets), due to the mux header - but it would be 
> straightforward to code an openssl BIO extension to allow 
> this if that were really important to someone.

My confusion stemmed from the fact that I had missed that you were using
openSSL in a completely different way from the way it is traditionally
used. I am not in agreement with the use of DTLS if we end up having to
play games on having the app invoke DTLS when it is convenient. I agree
to the use of DTLS, but in the traditional sense of having a port be
DTLS enabled (control), and one without. No MUX needed.

> 
> So, once again, let me summarize: using two unbound datagram 
> channels greatly complicates things when compared to this 
> approach. You need to create a binding between the two 
> channels somehow, you need to manage dual keep-alives (one 
> per channel), and there are more error conditions to manage 
> in the state machine.

Correct - and there are ways to do this. For instance, the combination
of the IP address and the Session ID would be one such way.

> 
> What are the benefits of the two-port approach that outweigh 
> these drawbacks?
The use of openSSL-read(), and the traditional use of DTLS, eliminating
the need to do a security review of how we actually use the protocol -
the whole reasoning for using a standard approach in the first place.

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