Subject: [OPSAWG] AD review: draft-ietf-opsawg-capwap-alt-tunnel-03

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Oct 2014 22:51:50 +0100

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 |
                +=====+

- 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 :-)

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

    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?

Regards, Benoit

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 28 Oct 2014 04:51:23 +0000

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-masked]
Cc: [email-masked]
Subject: AD review: draft-ietf-opsawg-capwap-alt-tunnel-03

Dear authors,

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

And as bonus points, a figure before that, to explain how CAPWAP works without local briding

               +-----+
               | WTP |
               +-----+\\
                       \\
                        \\

                  > This make sense. I will update the draft as above.

- Terminology
1. OLD:

NEW

> Yes, valid. I was copying the definition from 5415. But I shall make an additional note to clarify the local bridging

case.

-
               +-+-+-+-+-+-+                                  |
               | Tunnel    |                                  |
               | Failure   |                                  |
               +-+-+-+-+-+-+                                  |

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.

     *  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

      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

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Oct 2014 09:20:36 +0100

Hi Rajesh,

All your remarks make sense to me.

Regards, Benoit
> ------------------------------------------------------------------------
> *From:* Benoit Claise (bclaise)
> *Sent:* Monday, October 27, 2014 1:51 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* AD review: draft-ietf-opsawg-capwap-alt-tunnel-03
>
> Dear authors,
> 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?
> > 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.
> 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
> 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?
>
> (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,
>     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.