Hi All,
I am happy to join the I-D draft-ietf-opsawg-capwap-alt-tunnel, and help to
improve the document based on the comments received and recorded in this page
(https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel).
I revised the document and responded to all the existing comments as listed in
the attachments. Also thanks Joe Touch's comments, which I have solved in the
document. The major change include:
1. At the security aspect, we suggest using the IPSec to protect the data
tunnel between WTP and AR.
2. Add a new sub-element, "minimum IPv6 MTU", according to the suggestion from
Joe Touch.
3. Make it clear that "IEEE 802.11 WTP Alternate Tunnel Failure Indication" is
carried in "CAPWAP Station Configuration Request message".
4. Make it clear that we define seven sub-elements (each with its corresponding
type number). Three of them are specific for CAPWAP, one is specific for GRE,
and others are common ones. Make it clear that they can only be used as
sub-elements of "Alternate Tunnel Encapsulations Type message element" and
"IEEE 802.11 WTP Alternate Tunnel Failure Indication message element".
5. Change the structure of the draft. Firstly, introduce the three new "message
element"; secondly, introduce the three tunnel types; finnaly, introduce the
seven sub-elements involved.
6. Give more explanations to the GRE tunnel type.
Now I believe this document is ready to send to IESG. So I request for a WGLC.
And I will also help to reply any comments/questions during the following
procedure.
Regards,
Zongpeng
-----Original Message-----
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Thursday, May 04, 2017 10:46 AM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group
of the IETF.
Title : Alternate Tunnel Encapsulation for Data Frames in
CAPWAP
Authors : Rong Zhang
Rajesh S. Pazhyannur
Sri Gundavelli
Zhen Cao
Hui Deng
Zongpeng Du
Filename : draft-ietf-opsawg-capwap-alt-tunnel-09.txt
Pages : 26
Date : 2017-05-03
Abstract:
Control and Provisioning of Wireless Access Points (CAPWAP) defines a
specification to encapsulate a station's data frames between the
Wireless Transmission Point (WTP) and Access Controller (AC).
Specifically, the station's IEEE 802.11 data frames can be either
locally bridged or tunneled to the AC. When tunneled, a CAPWAP data
channel is used for tunneling. In many deployments encapsulating
data frames to an entity other than the AC (for example to an Access
Router (AR)) is desirable. Furthermore, it may also be desirable to
use different tunnel encapsulation modes between the WTP and the
Access Router. This document defines extension to CAPWAP protocol
for supporting this capability and refers to it as alternate tunnel
encapsulation. The alternate tunnel encapsulation allows 1) the WTP
to tunnel non-management data frames to an endpoint different from
the AC and 2) the WTP to tunnel using one of many known encapsulation
types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support
for alternate tunnel encapsulation during the discovery and join
process and AC may select one of the supported alternate tunnel
encapsulation types while configuring the WTP.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-09
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-09
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-09
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
I'm surprised to see security is optional and an assertion that RFCs published
in 2009 covers everything. Threats have evolved since then.
In looking at RFC5415, Section 12.1, I see:
Within CAPWAP, DTLS is used to secure the link between the WTP and
AC. In addition to securing control messages, it's also a link in
this chain of trust for establishing link layer keys. Consequently,
much rests on the security of DTLS.
In some CAPWAP deployment scenarios, there are two channels between
the WTP and AC: the control channel, carrying CAPWAP Control
messages, and the data channel, over which client data packets are
tunneled between the AC and WTP. Typically, the control channel is
secured by DTLS, while the data channel is not.
The use of parallel protected and unprotected channels deserves
special consideration, but does not create a threat. There are two
potential concerns: attempting to convert protected data into
unprotected data and attempting to convert un-protected data into
protected data. These concerns are addressed below.
Wouldn't interception and tampering of that traffic pose a threat? How about
gaining access to the control channel?
[duzongpeng]
In Security Considerations section of RFC 5415, the threats have been analyzed
including interception and tampering.
The control channel is mandatory for encryption. In CAPWAP, mature security
mechanism (DTLS) has been used to protect the control channel.
[/duzongpeng]
While I don't think this is the right draft to make changes for RFC5415, I
don't think it's adequate to say the control channel is optional for
encryption. I could see how the data might be handled elsewhere. The
description discusses this as talking to hundreds of thousands of access
points, isn't that access a threat?
[duzongpeng]
In RFC 5415, it is said that
CAPWAP Control messages, and optionally CAPWAP Data
messages, are secured using Datagram Transport Layer Security (DTLS)
[RFC4347].
So IMO, the control channel is mandatory for encryption.
[/duzongpeng]
This draft allows for additional encapsulation methods, we could require
encryption for these new encapsulation methods.
[duzongpeng]
In the deployment, for security consideration, we can deploy IPSec between WTP
and AR to protect the data channel.
[/duzongpeng]
This should probably be a discuss, so I would appreciate some discussion on
this to see if we have option here or if something will change in the
referenced RFCs soon.
[duzongpeng]
Agree.
[/duzongpeng]
+1 to Katleen's comment about optional data channel protection.
[duzongpeng] At the security aspect, we suggest using the IPSec to protect the
data tunnel between WTP and AR. [/duzongpeng]
In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication
Length == 4, but should it be >4 due to IPv4/IPv6 address at the end?
[duzongpeng] Change to >4, Thanks. [/duzongpeng]
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please treat these comments just like any other last call comments. For
more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-opsawg-capwap-alt-tunnel-08
Reviewer: Paul Kyzivat
Review Date: 2016-09-30
IETF LC End Date: 2016-09-30
IESG Telechat date: Not yet
Summary:
This draft is on the right track but has open issues, described in the review.
General Impression: I was able to generally understand what this document is
trying to do, and the details generally seem to be there.
But I was unable to put all the pieces together to make the entire thing work.
I think this is due to problems with the organization of the document and
possibly some missing pieces of information. I feel this document needs some
reorganization if it is to be understood by somebody new to it.
Issues:
Major: 5
Minor: 9
Nits: 0
(NOTE: I had a lot of trouble classifying the level of the issues. I finally
decided to classify the Major if there is insufficient information to do an
implementation. But take these classifications with a grain of salt.)
(1) MINOR: Normative language:
This document clearly intends to use normative language - there are numerous
occurrences of "MUST". However I also find a number of uses of "shall" (never
upper case) that appear to me to be intended as normative statements.
[duzongpeng] Change to MUST, and SHALL [/duzongpeng]
(2) MINOR: Figure 4:
This figure shows the WTP having two distinct Alternate Tunnels for SSID1. This
seems to imply that data traffic to/from SSID1 be classified and routed to one
or the other of these two tunnels. But I could find no discussion of any logic
for doing this.
[duzongpeng] Add a sentence:
AC can notify multiple AR addresses for load
balancing or redundancy. [/duzongpeng]
(3) MAJOR: Section 3 (Protocol Considerations):
This section has some organizational problems that make the document difficult
to. This is hinted at by the very vague title.
It defines three new CAPWAP message Elements, to be included in certain CAPWAP
messages:
- Supported Alternate Tunnel Encapsulations: is intended for inclusion in a
CAPWAP Join Request from a WTP to an AC.
- Alternate Tunnel Encapsulations: is intended for inclusion in an IEEE
802.11 WLAN Configuration Request message from an AC to a WTP.
- IEEE 802.11 WTP Alternate Tunnel Failure Indication: is intended for
inclusion in a CAPWAP messages from a WTP to an AC. The message type(s) that
should carry this were unclear to me, though probably evident to someone
familiar with CAPWAP.
[duzongpeng] Add a sentence:
It MAY be carried in the CAPWAP Station Configuration Request message which is
defined in [RFC5415]. [/duzongpeng]
An extensible set of Alternate Tunnel Encapsulation types is defined.
These are referenced by both Supported Alternate Tunnel Encapsulations and
Alternate Tunnel Encapsulations.
Each of these requires specification of an Information Element used to
configure it. The document defines only three of the these. (The definition of
the others is deferred to future documents.) The definitions of these are also
direct subsections of section 3, though they are a very different sort of thing
than the earlier subsections.
[duzongpeng] The structure is changed according to your suggestion.
[/duzongpeng]
Of these three, two are quite simple and understandable. The third (GRE)
appears to be very complex, with nested sub-elements. I was unable to fully
decipher this. (More below.)
[duzongpeng] Explanations are added according to your suggestion. [/duzongpeng]
(4) MINOR: Section 3.2 (Alternate Tunnel Encapsulations Type):
Section 3.1 shows the Tunnel-Type being carried in an 8-bit field, while
section 3.2 uses a 16-bit field. The actual values are defined in section 3.2
and include only values 0-6, with other values reserved for future use. The
IANA Considerations section defines this as a 16-bit value.
It might be wise to restrict this to 8-bits in the IANA considerations, and in
section 3.2 reserve the first 8 bits of the type field, as in:
[duzongpeng] Change to 16bits. [/duzongpeng]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Tunnel-Type | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info Element
+-+-+-+-+-+-+-+-+-+
While this section defines a new registry of tunnel types, and formats for
descriptive information element about each, there seem to be no rules for
defining new values.
[duzongpeng] Other tunnel types can be handled likewise.
Also, in the IANA part, there are some explanations:
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.. [/duzongpeng]
Also, I had trouble figuring out which portions of this document are defining
Information Elements for use in this message, and which are defining something
else. It would help if the description of each tunnel type in the list in this
section had a cross reference to the section that defines the Information
Element for that type. (But a more major reorganization would be better.)
[duzongpeng] Seven sub-elements are defined, in which three are specific for
CAPWAP, one is specific for GRE, and others are common ones. [/duzongpeng]
(5) MAJOR: Section 3.4 (CAPWAP based Alternate Tunnel):
For the CAPWAP Transport Protocol Element the description mentions two possible
values (UDP and UDP-Lite), but fails to state what encoding is used to
designate them.
[duzongpeng] 1 for UDP-lite, and 2 for UDP, as defined in RFC5415.
[/duzongpeng]
(6) MAJOR: Section 3.6 (GRE based Alternate Tunnel):
Based on section 3.2, I was expecting the definition of *one* information
element format for GRE tunnels. But this section says "The information
element*s* needed for supporting this mode are defined in Section 3.7 and
Section 3.7.6." and proceeds to define more than one.
And referencing both 3.7 and 3.7.6 seems at least odd. I suspect the reference
to 3.7.6 is a mistake because there seems nothing special about it.
[duzongpeng] It has been changed. [/duzongpeng]
(7) MAJOR: Section 3.7 (Alternate Tunnel Information Elements):
It appears that sections 3.7.n define sub-elements of an overall GRE
Information Element, but I find no definition of that overall element.
[duzongpeng] It has been changed. [/duzongpeng]
(8) MINOR: Section 3.7.1 (Access Router Information Elements):
This says: "The AR information may be IPv4 address, IPv6 address, or AR domain
name." Then it has subsections defining IPv4 and IPv6 addresses.
But I can find nothing that says how to specify a domain name.
[duzongpeng] It has been changed. Thanks. [/duzongpeng]
(9) MAJOR: Section 3.7.1.1 (AR IPv4 List Element):
This section seems to call for a constant value designating "AR IPv4 Element
Type" but I find no specification of what that value might be.
[duzongpeng] It has been added. Thanks. [/duzongpeng]
(10) MAJOR: Section 3.7.1.2 (AR IPv6 List Element):
This section seems to call for a constant value designating "AR IPv6 Element
Type" but I find no specification of what that value might be.
[duzongpeng] It has been added. Thanks. [/duzongpeng]
(11) MAJOR: Section 3.7.2 (IEEE 802.11 WLAN Configuration Response):
I thought this section should be defining part of the Information Element for
the Alternate Tunnel Encapsulation Type message element from the AC to the WTP.
Yet this section says that it is intended to be sent from the WTP the the AC.
This left me scratching my head as to what it is and where it goes.
[duzongpeng] It's place has been changed into the introduction. Thanks.
[/duzongpeng]
(12) MAJOR: Section 3.7.3 (Tunnel DTLS Policy Element):
I don't understand where this element is intended to be inserted.
[duzongpeng] It is one of the sub-elements when the CAPWAP alternative tunnel
type is used. [/duzongpeng]
The title of this section is "Tunnel DTLS Policy Element", but in figure
13 the type field is called "Tunnel DTLS Element Type". Why are these
different? Also, I find no defined numeric value for this field.
[duzongpeng] It has been changed. Thanks. [/duzongpeng]
(13) MAJOR: Section 3.7.4 (IEEE 802.11 Tagging Mode Policy Element):
This references the 802.11 Tagging Mode Policy in RFC5416. But I was unable to
decipher how that relates to the Alternate Tunnel Encapsulation Type message.
[duzongpeng] It is one of the sub-elements when the CAPWAP alternative tunnel
type is used. [/duzongpeng]
(14) MINOR: Section 4 (IANA Considerations):
This asks IANA to create a new registry of Alternate tunnel types. The only
values in the registry for each type are the numeric value, a human friendly
name, and a reference. The references are to the definitions of the underlying
tunnel protocols.
I understand, this isn't sufficient information to use these values. It is also
necessary to know the format of the associated Information Element for each
type. For *some* of the types that information is present in this document. For
others that information is left for future definition, presumably in some new
document.
[duzongpeng] Three of them can be found in this document. In the new Section
4, CAPWAP, PMIP, and GRE¡¯s associated Information Element are introduced.
As said in the document, other tunnel types will not be discussed in this
document, and perhaps will be defined in some new document.[/duzongpeng]
The registry needs to have a reference to a document specifying the format of
the Information Element for the type.
Also, it would be very helpful if there was a template for how to specify the
Information Element for a type, and for this document to follow that format for
the ones it defines.
[duzongpeng]
This document has provide three examples, and other tunnel types can be defined
likewise while considering the protocol specific characteristics.
[/duzongpeng]
Nit:
s/This specification defines the values from zero (0) to five (5)/This
specification defines the values from zero (0) to six (6)/
[duzongpeng] Changed. Thanks. [/duzongpeng]
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
This draft describes an extension to the Control and Provisioning of Wireless
Access Points (CAPWAP) protocol that encapsulates a station¡¯s data frames
between the Wireless Transition Point (ATP) and Access Controller (AC). In
some cases, it may be desirable to encapsulate data frames to an entity other
than the AC (e.g. to an Access Router) or to use different encapsulation
models. In particular, this would allow the WTP to tunnel non-management data
frames to an endpoint different than the AC and to tunnel using different known
encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. A particular advantage
of this approach that encapsulating only the control plane to the AC, and thus
separating management of the control plane from the management of the data
plane, makes scaling easier and more efficient.
As far as I can tell, there do not seem to be any serious security issues with
implementing this approach, especially since, as is noted in RFC [RFC5415], the
data plane is already handled differently from the control plane, the control
plane usually being protected by DTLS while the data plan is not. However, I
think the Security Considerations Section needs to make a better case for this.
The text of the Security Considerations section is as follows:
This document introduces three new CAPWAP WTP message elements.
These elements are transported within CAPWAP Control messages as the
existing message elements. Therefore, this document does not
introduce any new security risks compared to [RFC5415] and [RFC5416].
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. The security considerations described in
[RFC5415] and [RFC5416] apply here as well.
I find it hard to agree with the first three sentences. The document does more
than simply introduce three new message elements. It also provides
considerably more freedom in encapsulating data frames. So it appears to me
that what the Security Considerations section should concentrate on is the
potential risk in providing this greater freedom.
[duzongpeng]
Add some descriptions:
In the data plane, if the encapsulation type selected itself is not secured, it
is suggested to protect the tunnel by using known secure methods, such as
IPSec. [/duzongpeng]
It¡¯s also not clear to me what the purpose of the remaining part of the
section, about the AC determining the policy. Are you saying that, because the
AC determines the policy in both CAPWAP and the CAPWAP extension, the security
considerations for the first case also apply to the second case? Some more
discussion of why this is true, with references to the relevant risks discussed
in [RFC5415] and [RFC5416], would be useful.
[duzongpeng] Delete the second part. I also find it is hard to understand
the purpose of that part. [/duzongpeng]
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
