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