Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
RFC 8350

Note: This ballot was opened for revision 08 and is now closed.

(Joel Jaeggli) (was Yes) Discuss

Discuss (2016-10-24 for -08)
sorry we came to some comclusions on the basis of late review that make this hard to advance without correcting.

this will be withdrawn from this review cycle.

Warren Kumari Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-01-23 for -11)
No email
send info
-1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms.

-1.3: Serving as an "archival record" seems like an odd use of "experimental". That sounds more "informational" to me.

-7: I agree with Kathleen's comments about the security considerations.

Editorial Comments and Nits:

- The abbreviations that were expanded in the abstract should be expanded again on the body.

-1, paragraph after figure 1: Missing article before the first occurrence of "CAPWAP".

-1.3, first sentence: " Service Provider's " should either be " Service Providers' " or "the Service Provider's

-2, 3rd paragraph after figure 5: Missing article before WTP (multiple occurrences).

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Suresh Krishnan) (was Discuss) No Objection

Comment (2018-01-29)
No email
send info
Thanks for addressing my DISCUSS.

(Mirja Kühlewind) No Objection

Comment (2016-10-24 for -08)
No email
send info

s/This specification defines the values from zero (0) to five (5)/This specification defines the values from zero (0) to six (6)/

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2016-10-23 for -08)
No email
send info
+1 to Katleen's comment about optional data channel protection.

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?

(Kathleen Moriarty) No Objection

Comment (2016-10-23 for -08)
No email
send info
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?

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?  

This draft allows for additional encapsulation methods, we could require encryption for these new encapsulation methods.

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.

Thank you.

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-01-24 for -11)
No email
send info
I have run out of time to fully review this document before the telechat, and it is sufficiently outside my area of expertise that I do not believe that the input I could provide is valuable enough to warrant deferring.

However, I want to put a fine point on Ben's comment ("§1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms.")  The IETF has a long-established policy in this area, summarized in RFC 2804 as: "The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards."

If you can remove the mention of lawful intercept from this document and the justification for the described configuration still makes sense (as I believe it does), please do so. If you think that the removal of lawful intercept from this section tangibly changes the rationale for the design described in this document, please let me know, and I'll change my position to DISCUSS while we figure out what needs to happen.