Capwap Mailing List: RE: NAT-T

[Scott G. Kelly (s.kelly]

Yes, I'm suggesting use of one port with a mux header rather than 2 ports: it's 
much simpler operationally.

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
>Sent: Mar 22, 2006 11:27 AM
>To: "Scott G. Kelly" <scott [at] hyperthought.com>, capwap <capwap [at] 
>frascone.com>
>Subject: RE: [Capwap] NAT-T
>
>Scott,
>
>I'm not sure I follow.
>
>Are you stating that the MUX is a replacement for the dual UDP port
>solution? The latter allows existing NATs to handle the packet, while
>the MUX is useful at the application layer. That said, I'm not sure that
>I understand why we cannot rely on the BSSID in the 802.11 frame to
>identify the WTP.
>
>Pat Calhoun
>CTO, Wireless Networking Business Unit
>Cisco Systems
>
> 
>
>> -----Original Message-----
>> From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
>> Sent: Wednesday, March 22, 2006 8:53 AM
>> To: capwap
>> Subject: [Capwap] NAT-T
>> 
>> Hi All,
>> 
>> A group of us met yesterday to discuss dtls integration, and 
>> one related design point pertains to nat traversal. In 
>> particular, how we decide to handle directly impacts the 
>> design for dtls integration, so we want to get this resolved ASAP.
>> 
>> In the original lwapp-dtls draft, we discussed two options 
>> for differentiation: use a mux header, or use separate UDP 
>> ports, one for data and one for control. Initial agreement 
>> seems to be on the two-port approach, but this has nat-t implications.
>> 
>> Assume we're using two ports; in that case, the problem we 
>> have to solve is many ways similar to the one solved by the 
>> ipsec group (I'll use NAT rather than NAPT, as it's simpler 
>> to type :-)):
>> 
>> - the WTP sends a DISCOVER to the AC; note that if this is 
>> broadcast, no reply would be possible using a standard NAT 
>> implementation, as the NAT binding would be to the tuple 
>> (WTP-IP, BCAST-IP, UDP, WTP-PORT, AC-PORT). Since the 
>> response would not be from BCAST-IP, standard NAT 
>> implementations would drop it. This implies directed DISCOVER messages
>> 
>> - *if* the AC responds within the NAT binding timeout period 
>> (while the mapping record still exists on the middlebox), the 
>> WTP will receive the response; otherwise, it will be silently dropped
>> 
>> - assuming the WTP receives the response and wants to 
>> associate with the AC, it initiates the JOIN process (yes, 
>> the JOIN must be brought back, more on that later). One or 
>> both sides must also start a heartbeat over this channel in 
>> order to keep the NAPT binding(s) active.
>> 
>> - one point we skipped is that of NAT detection. You could 
>> always send heartbeats, regardless of the presence of NAT, 
>> but if you use the two-port method, you must detect NAT in 
>> any case (for reasons that will become obvious soon). The way 
>> IPsec handled this is to have the WTP include it's IP and 
>> port in one of the messages (in our case, during the JOIN), 
>> and having the AC compare this to the adress in the packet 
>> header; if they differ, the AC must inform the WTP of this in 
>> the response.
>> 
>> - NAT detection may be used as an indicator that heartbeat 
>> messages are needed. Note that the interval should probably 
>> be configurable (with sensible defaults),  as there is no 
>> standard NAT mapping lifetime.
>> 
>> Okay, so now we have the control channel. The first data 
>> channel message must be from a STA trying to associate. The 
>> WTP bundles this up and sends it to the AC - how does the AC 
>> associate this with a given WTP? Note that there is no 
>> guarantee the data channel will have the same source address 
>> as the control channel (L3 switching, load balancing), so we 
>> need a binding mechanism to associate the data and control 
>> channels, from the AC's perspective.
>> 
>> We could do this by placing the same session ID as used for 
>> the control channel into the data channel capwap header, but 
>> this header will be encrypted once dtls starts, adding some 
>> complexity to packet handling. Also, we need to manage 
>> heartbeats over this channel as well, and since we're doing 
>> dtls on this channel, we have to decide whether to encrypt 
>> these or not. If we don't, we've added new processing 
>> coplexity on both sides. If we do, we're chewing through our 
>> counter/iv space, meaning we have to take the heartbeat 
>> interval into rekey consideration for purposes of lifetime 
>> computations.
>> 
>> Okay, so clearly, using separate ports has some complexity 
>> associated with it. What about using a mux header instead? By 
>> this, I mean adding a field between the udp header and the 
>> 'data' (capwap header or dtls record layer header) to 
>> distinguish the two:
>> 
>> +----+-----+------+---------+
>> |  IP | UDP | mux | data    |
>> +----+-----+------+---------+
>> 
>> Let's say the mux header is 32 bits, and we use only one of 
>> these (for the time being) to indicate control/data (this is  
>> much like the lwapp 'c' bit). What are the differences in 
>> this approach? Two issues have been raised:
>> 
>> - it adds 4 bytes to the packet
>> 
>> - it is unprotected
>> 
>> To the first, I would reply that this is a trade-off, the 
>> price you pay for greatly reduced complexity. But yes, the 
>> cost is 4 bytes
>> 
>> To the second point, I would reply that Eric addressed this 
>> in the security considerations of the lwapp-dtls draft: there 
>> are two things an adversary might attempt here: converting 
>> protected data into unprotected data (data channel into 
>> control channel), and vice versa. 
>> 
>> Now, keep in mind that an attacker must be a MiM to do this, 
>> implying they can insert and delete packets at will anyway. 
>> If the adversary converts a data packet (unencrypted) to a 
>> control packet, decryption/authentication will fail, and this 
>> will be detected. If the adversary converts a control packet 
>> (encrypted, authenticated) to a data packet, it will be 
>> interpreted as garbage - again, it will be detected. 
>> 
>> The bottom line: there is no threat here that does not exist 
>> in the two-port case. They are equivalent in this respect. 
>> 
>> In the plus column, I think we can say that the mux header 
>> approach is simpler, in that the NAT-T concerns only apply to 
>> one channel, and the binding between control and data 
>> channels is unambiguous. Further, it gives the ability to 
>> provide a single de-muxing channel in the code for inbound 
>> packet handling, which may be advantageous, depending on 
>> implementation nuances.
>> 
>> We decided at our meeting yesterday that for these reasons, 
>> the mux header approach seems the most sensible. Does anyone object?
>> 
>> --Scott
>> 
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>> 
>> Archives: http://lists.frascone.com/pipermail/capwap
>>