Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Sun, 23 Oct 2016 09:57:25 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Duzongpeng <[email-masked]>
Date: Tue, 25 Oct 2016 12:41:45 +0000

Hello,

	I would like to give some suggestions as below.

	Some operators deploys their WiFi networks with the data channel unsecured, and even for the wireless part, there are some unsecured deployment examples.
	It is not a good choice; however, it is simpler.

	Of course, some secure ensured methods should also be provided.
	For the wireless part, IEEE has provided several secure mechanism;
	For the wireline part, IPsec can be deployed to protect the security.

	Would it be ok for the draft to suggest that IPsec should be deployed if the tunnel type itself is unsecured.

Best Regards
Zongpeng Du

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Monday, October 24, 2016 12:57 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

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:

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.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Oct 2016 15:24:29 +0200

>         Would it be ok for the draft to suggest that IPsec should be deployed if the tunnel type itself is unsecured.

Personally I don't think that this is a useful suggestion -- *who*
exactly would you be advising to do this? Users? They don't (and
shouldn't have to) read the RFCs. Suggesting something which we know
will not be used seems disingenuous - acknowledging that this is a
real issue seems better than suggesting something which we know won't
be done to users who we know are not reachable.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Oct 2016 09:47:25 -0400

On Tue, Oct 25, 2016 at 9:24 AM, Warren Kumari <[email-masked]> wrote:

> >         Some operators deploys their WiFi networks with the data channel
> unsecured, and even for the wireless part, there are some unsecured
> deployment examples.
> >         Would it be ok for the draft to suggest that IPsec should be
> deployed if the tunnel type itself is unsecured.
>
>

For this draft and the protocol, we are more worried about MTI, not MTU so
that the option is there and traffic can be encrypted.  Then encouraging
the use of encryption is possible.

Kathleen

> > Subject: [OPSAWG] Kathleen Moriarty's No Objection on
> draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)
> >

-- 

Best regards,
Kathleen

---

From: joel jaeggli <[email-masked]>
Date: Tue, 25 Oct 2016 11:31:20 -0700

> be done to users who we know are not reachable.

indeed, ipsec has a tendency to only be used by consenting adults on the
basis of prior coordination. if it's a mnadatory component if a design
that cannot be deployed without it, great; if not it smacks of a token
gesture.

---

From: Duzongpeng <[email-masked]>
Date: Wed, 26 Oct 2016 01:50:16 +0000

Hi, Warren

	Thanks for your reply. I want to clarify that I am not suggesting users to use IPsec.

	In the draft, the tunnels between the WTP and AR need to be protected, so the IPsec is between the WTP and AR.

	The network provide is responsible for the security of the users, and should deploy the IPSec between the WTP and AR.

	We can suggest to the network providers that it is not a good choice to use unsecured tunnel.
	Also, the network provide should notify the users that the service is unsecured if they choose some unsecured tunnel types.

Best Regards
Zongpeng Du

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2016 9:24 PM
To: Duzongpeng
Cc: Kathleen Moriarty; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

>         Would it be ok for the draft to suggest that IPsec should be deployed if the tunnel type itself is unsecured.

Personally I don't think that this is a useful suggestion -- *who* exactly would you be advising to do this? Users? They don't (and shouldn't have to) read the RFCs. Suggesting something which we know will not be used seems disingenuous - acknowledging that this is a real issue seems better than suggesting something which we know won't be done to users who we know are not reachable.
W

> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Oct 2016 13:43:29 +0900

> In the draft, the tunnels between the WTP and AR need to be
> protected, so the IPsec is between the WTP and AR.
> 
> The network provide is responsible for the security of the
> users, and should deploy the IPSec between the WTP and AR.
> 
> We can suggest to the network providers that it is not a good
> choice to use unsecured tunnel.  Also, the network provide
> should notify the users that the service is unsecured if they
> choose some unsecured tunnel types.

on my more paranoid days, this being one, i think ipsec was designed to
deter use and hence privacy; we have become married to sabatoge.

is there some simpler easily deployed auth/privacy mechanism which could
be mti?  md5/4808 would at least be deployable, disgusting as it is.

randy

---

From: Duzongpeng <[email-masked]>
Date: Wed, 26 Oct 2016 07:14:24 +0000

Hi, Randy

	I agree that other solutions exist. But IPSec should be the preferred one by the public WiFi operators because it is more mature and widely used.
	Of course, we can clarify that other solutions are also ok for protecting the security of the users.

Best Regards
Zongpeng Du

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Wednesday, October 26, 2016 12:43 PM
To: Duzongpeng
Cc: Warren Kumari; Kathleen Moriarty; The IESG; [email-masked]
Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

> The network provide is responsible for the security of the users, and 
> should deploy the IPSec between the WTP and AR.
> 
> We can suggest to the network providers that it is not a good choice 
> to use unsecured tunnel.  Also, the network provide should notify the 
> users that the service is unsecured if they choose some unsecured 
> tunnel types.

on my more paranoid days, this being one, i think ipsec was designed to deter use and hence privacy; we have become married to sabatoge.

is there some simpler easily deployed auth/privacy mechanism which could be mti?  md5/4808 would at least be deployable, disgusting as it is.

randy

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Oct 2016 12:37:43 +0200

>         Thanks for your reply. I want to clarify that I am not suggesting users to use IPsec.

In that case I completely misunderstood and take back my grumpiness.

>         In the draft, the tunnels between the WTP and AR need to be protected, so the IPsec is between the WTP and AR.

Got it.
W