Hello Benoit Thanks for reviewing the draft. Overall the comments make sense and I will incorporate the suggested changes. Some follow up remarks are embedded.
regards Rajesh ________________________________ From: Benoit Claise (bclaise) Sent: Monday, October 27, 2014 1:51 PM To: [email protected] Cc: [email protected] Subject: AD review: draft-ietf-opsawg-capwap-alt-tunnel-03 Dear authors, The CAPWAP Data channel carries the IEEE 802.11 management traffic (like IEEE 802.11 Action Frames). The station's data frames are locally bridged, i.e., not carried over the CAPWAP data channel. The station's data frames are handled by the Access Router. Data Channel, Data channel, data channel. Be consistent That was one source of confusion (had to re-read the text) Later on, I see As shown in the figure there is still a CAPWAP control and data channel between the WTP and AC, wherein the CAPWAP data channel carries the stations' management traffic. That's the point, the figures 1 and 2 don't show the CAPWAP control and data channels. The figures would benefit from something like this Locally Bridged +-----+ Data Frames +----------------+ | WTP |==================| Access Router | +-----+\\ +----------------+ \\ \\ \\ CAPWAP Control Channel: +--------+ ++=========================+ AC | // CAPWAP Data Channel: +--------+ // IEEE 802.11 management traffic // +-----+// +----------------+ | WTP |==================| Access Router | +=====+ Locally Bridged +----------------+ Data Frames Figure 1: Centralized Control with Distributed Data And as bonus points, a figure before that, to explain how CAPWAP works without local briding +-----+ | WTP | +-----+\\ \\ \\ \\ CAPWAP Control Channel: +--------+ ++=========================+ AC | // CAPWAP Data Channel: +--------+ // - IEEE 802.11 management traffic // - Data Frames +-----+// | WTP | +=====+ > This make sense. I will update the draft as above. - Terminology 1. OLD: Wireless Termination Point (WTP), The physical or network entity that contains an RF antenna and wireless Physical Layer (PHY) to transmit and receive station traffic for wireless access networks. NEW Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless Physical Layer (PHY) to transmit and receive station traffic for wireless access networks. 2. I guess that the definitions comes from the CAPWAP RFCs. You might want to provide references 3. CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data packets are sent and received. Well, if the mode is local bridging, not quite :-) > Yes, valid. I was copying the definition from 5415. But I shall make an > additional note to clarify the local bridging case. - +-+-+-+-+-+-+ | | Tunnel | | | Failure | | +-+-+-+-+-+-+ | |WTP Alternate Tunnel Failure Indication | |(report failure) | |---------------------------------------->| | | +-+-+-+-+-+-+-+ | | Tunnel | | | Established | | +-+-+-+-+-+-+-+ | |WTP Alternate Tunnel Failure Indication | |(report clearing failure) | |---------------------------------------->| | | Figure 3: Setup of Alternate Tunnel What if no tunnels can be established. What is the default behavior: all data frames sent to the AC? Or no communication? Or it is simply an AC deployment decision? Maybe you want a have sentence such as > Good point. if the tunnel is not established then the WTP would send a > Failure Response Code as part of WLAN Configuration Request. If the tunnel > fails after establishment, then the data frames should be dropped. Sending to > AC is not advisable because it is possible that the AC may not be capable to > handling the data frames. I am thinking of something along the following > lines. On detecting a tunnel failure, WTP shall drop client packets. In addition, WTP may dissociate existing clients and refuse association requests from new clients. Depending on the implementation and deployment scenario, the AC may choose to reconfigure the WLAN (on the WTP) to a local bridging mode or to tunnel frames to the AC. For the case where AC is unreachable but the tunnel end point is still reachable, the WTP behavior is up to the implementation. For example, the WTP could either choose to tear down the tunnel or let the existing user's traffic continue to be tunneled. - I don't feel comfortable with * 0: CAPWAP. This refers to a CAPWAP data channel described in [RFC5415<http://tools.ietf.org/html/rfc5415>][RFC5416]. Additional description in [I-D.xue-opsawg-capwap-alt-tunnel-information<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>]. * 1: L2TP. This refers to tunnel encapsulation described in [RFC2661<http://tools.ietf.org/html/rfc2661>]. * 2: L2TPv3. This refers to tunnel encapsulation described in [RFC3931<http://tools.ietf.org/html/rfc3931>]. * 3: IP-in-IP. This refers to tunnel encapsulation described in [RFC2003<http://tools.ietf.org/html/rfc2003>]. * 4: PMIPv6. This refers to the tunneling encapsulation described in [RFC5213<http://tools.ietf.org/html/rfc5213>] * 5: GRE-IPv4. This refers to GRE encapsulation with IPv4 as the delivery protocol as described in [RFC2784<http://tools.ietf.org/html/rfc2784>] * 6: GRE-IPv6. This refers to GRE encapsulation with IPv6 as the delivery protocol as described in [RFC2784<http://tools.ietf.org/html/rfc2784>] And Tunnel-Type: This specification defines the Alternate Tunnel Encapsulations Type message element. This element contains a field Tunnel-Type. The namespace for the field is 16 bits (0-65535)). This specification defines values, zero (0) through six (6) and can be found in Section 3.2<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#section-3.2>. Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy. IANA needs to create a registry called CAPWAP Alternate Tunnel-Types. The registry format is given below. Tunnel-Type Type Value Reference CAPWAP 0 L2TP 1 L2TPv3 2 IP-IP 3 PMIPv6 4 GRE-IPv4 5 GRE-IPv6 6 In the first paragraph, you give the references, which is good. So they should be in the IANA section (second paragraph) as well. Btw, you have foreseen the Reference column. Then comes the problem, you can't have a reference in IANA to [I-D.xue-opsawg-capwap-alt-tunnel-information<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>], which is btw an informative reference in the draft, and not even a WG document. So the question is: do you need the reference to this draft in paragraph 1. I don't think so. OLD: * 0: CAPWAP. This refers to a CAPWAP data channel described in [RFC5415<http://tools.ietf.org/html/rfc5415>][RFC5416]. Additional description in [I-D.xue-opsawg-capwap-alt-tunnel-information<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>] NEW: * 0: CAPWAP. This refers to a CAPWAP data channel described in [RFC5415<http://tools.ietf.org/html/rfc5415>][RFC5416]. - Security Considerations. So you're telling that, because the CAPWAP Control Channel is protected by DTLS, there are no chance for someone else that the AC to send or resend a WLAN Config. Response to redirect the traffic to another tunnel destination? What if someone just pretends to the tunnel end point? (Yes, the behavior would depend on the security policy for the alternate tunnel. If there is no security, someone can pretend to be the tunnel end point. However, if the tunnels are secured using IPSec or DTLS, then masquerading the tunnel end point would not be possible.) > Yes. the CAPWAP messaging is protected by DTLS. How about the following text. This document introduces three new CAPWAP WTP message elements. These elements are transported within CAPWAP Control messages as the existing message elements. These messages are transported using DTLS. Therefore, this document does not introduce any new security risks compared to [RFC5415<http://tools.ietf.org/html/rfc5415>] and [RFC5416<http://tools.ietf.org/html/rfc5416>]. The security considerations described in [RFC5415<http://tools.ietf.org/html/rfc5415>] and [RFC5416<http://tools.ietf.org/html/rfc5416>] apply here as well. In CAPWAP, security for CAPWAP Data Channel is optional and security policy is determined by AC. Similarly, the AC determines the security for the Alternate Tunnel between WTP and Alternate Tunnel Encapsulation Gateway. Regards, Benoit
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
