Subject: RE: [Capwap] NAT-T

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 24 Mar 2006 09:40:11 -0800 (GMT-08:00)

Hi Pat,

<much trimmed...>

>> Tthe 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.

There is no game-playing here - this is exactly what lwapp does today: look at a header field and branch based on whether it's a control packet or a data packet. Is there something technically wrong with this?

As for openssl tradition, openssl supports the BIO abstraction, which allows all sorts of "traditional" approaches to input/output. I think by traditional, you probably mean "socket", but that is a misconception. But this is a distraction, and here's why: openssl is not the security protocol here; DTLS is. Openssl provides one example of an open-source implementation of DTLS, but there are others - and there is no requirement that our solution conform to one particular open-source interpretation. Rather, we should aim to conform to the DTLS specification.

If this socket issue is the only complaint you have, I think we can find someone to provide the community with a dtls extension BIO for openssl which ignores the mux header (or in general, n bytes at the beginning of the buffer). I'm sure this would be useful for other applications. Will that address your concerns? Having spent a significant portion of the last few months knee-deep in the openssl dtls code, I can assert authoritatively that this is not a difficult thing to add, and it will have absolutely no impact on the security properties of dtls. 

And I think this is an important enough point that I want to emphasize it again: however one particular openssl implementer chose to render one particular embodiment of DTLS, we shlould not be discussing standardizing on that API. I can just about guarantee that if we try to send through a standards document which depends on openssl, the security ADs will send this back for a do-over. Openssl is not a standard - it's an open-source implementation.

>> 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.

Of course there are ways to do it - but the two-port approach is more painful and prone to implementation error, and the state machine is much simpler if we don't go this route. Simpler implementations are almost certainly more secure. Your current implementation already does what I am proposing. I don't understand the resistance.

>> 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.

I think the fear of additional security review is a bit irrational. If we use the protocol according to specification, no additional security review will be required (beyond the ongoing review we will be conducting in any event). We are not talking about hacking dtls in any way. We are talking about using it in completely standard way. But again, let me underscore the point: DTLS is the standard; openssl is *not*. Let's not confuse these.

Scott

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

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

---

From: [email-masked]
Date: Sat, 25 Mar 2006 12:20:01 +0530

Hi Scott,

Very keen on seeing your next draft on NAT-T, esp the topologies that you
have considered. If it is just a matter of forwarding one email to the
group, can you share the objectives of NAT-T?

Assuming a traditional NAT device that supports port-forwarding, is there
any restriction on where we place AC/WTP (w.r.t. public-private network).
Also, tunneling data-packets to a different AC must be covered. In that
case, WTP must detect NAT device in the path to data-AC and may have to run
two keepalives. There are other requirements which I am sure are covered. If
there is a writeup or some text on these, please share it.

Regards,
-Rajesh Mohan

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]]
Sent: Friday, March 24, 2006 11:10 PM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: RE: [Capwap] NAT-T

Hi Pat,

<much trimmed...>

>DTLS enabled (control), and one without. No MUX needed.

There is no game-playing here - this is exactly what lwapp does today: look
at a header field and branch based on whether it's a control packet or a
data packet. Is there something technically wrong with this?

As for openssl tradition, openssl supports the BIO abstraction, which allows
all sorts of "traditional" approaches to input/output. I think by
traditional, you probably mean "socket", but that is a misconception. But
this is a distraction, and here's why: openssl is not the security protocol
here; DTLS is. Openssl provides one example of an open-source implementation
of DTLS, but there are others - and there is no requirement that our
solution conform to one particular open-source interpretation. Rather, we
should aim to conform to the DTLS specification.

If this socket issue is the only complaint you have, I think we can find
someone to provide the community with a dtls extension BIO for openssl which
ignores the mux header (or in general, n bytes at the beginning of the
buffer). I'm sure this would be useful for other applications. Will that
address your concerns? Having spent a significant portion of the last few
months knee-deep in the openssl dtls code, I can assert authoritatively that
this is not a difficult thing to add, and it will have absolutely no impact
on the security properties of dtls.

And I think this is an important enough point that I want to emphasize it
again: however one particular openssl implementer chose to render one
particular embodiment of DTLS, we shlould not be discussing standardizing on
that API. I can just about guarantee that if we try to send through a
standards document which depends on openssl, the security ADs will send this
back for a do-over. Openssl is not a standard - it's an open-source
implementation.

>of the IP address and the Session ID would be one such way.

Of course there are ways to do it - but the two-port approach is more
painful and prone to implementation error, and the state machine is much
simpler if we don't go this route. Simpler implementations are almost
certainly more secure. Your current implementation already does what I am
proposing. I don't understand the resistance.

>the whole reasoning for using a standard approach in the first place.

I think the fear of additional security review is a bit irrational. If we
use the protocol according to specification, no additional security review
will be required (beyond the ongoing review we will be conducting in any
event). We are not talking about hacking dtls in any way. We are talking
about using it in completely standard way. But again, let me underscore the
point: DTLS is the standard; openssl is *not*. Let's not confuse these.

Scott

---

From: Scott G Kelly <[email-masked]>
Date: Sat, 25 Mar 2006 09:22:22 -0800

Hi Rajesh,

> there is a writeup or some text on these, please share it.

To be clear, I have no intention of writing a draft on this at this 
time. However, I've asked before if people would detail the NAT 
scenarios they think must be supported, but nobody gave any detail.

Personally, I think most such scenarios require a VPN between the two 
network edges (for security reasons), so this is more a routing problem 
than a NAT-T problem. Some folks might object to this assessment, yet 
none seem willing to detail concrete examples. I think that in order to 
assess requirements, we need a complete enumeration of use cases. Short 
of that, I don't think we should consider NAT-T.

Scott